[cabfpub] Urgent: BR Exceptions for Subordinate CA Certificates

[Eddy Nigg (StartCom Ltd.)]

On 11/01/2013 01:12 PM, From Gervase Markham:
>
> Quite so. The question here is not "are such practices acceptable when
> new roots are created" - clearly, they are not. The question is: how do
> we deal with this compatibility issue we have with a legacy root with an
> unfortunate name?

I'm sure there are and will be other issues that are unfortunate I guess 
- key sizes, hashes, EKUs, CRLs, OCSP and much more...now where to draw 
the line?

> You can argue, if you like, that roots issued before the BRs were
> thought of and so which don't meet them should be immediately abandoned,
> and nothing should ever be done to enable them to continue to function
> for one second more, but normally the CABF has a less drastic approach
> to backwards compatibility than that.

In this case it's not a root (of Verizon) but an intermediate CA to 
them. I agree that there is some pragmatism as work and the forum, on 
the other hand this isn't all new to them either and has been on the map 
for a while (for both BIT and for Verizon). It's certainly a headache to 
them, but I have a problem with the browser showing "*admin*" as the 
issuing authority (not stating the various reasons now).


Regards
Signer: 	Eddy Nigg, COO/CTO
	StartCom Ltd. <http://www.startcom.org>
XMPP: 	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Twitter: 	Follow Me <http://twitter.com/eddy_nigg>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131101/037fe41d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4540 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131101/037fe41d/attachment-0001.p7s>