Re: Comodo request for EV-enabling 3 existing roots

[Eddy Nigg (StartCom Ltd.)]

Rob Stradling:
> Frank, thanks for your detailed explanation.  I concur with everything you've 
> said, but I'd just like to add a couple of additional comments (inline) in 
> reply to Eddy...
>   
Hi Rob,
>
> For the record, I can assure you that Comodo never issue DV and EV certs from 
> the same Intermediate CA.
>   
In that case we need to update our papers then. For example I've 
received the following comment from Frank previously concerning the 
adding of the "|COMODO Certification Authority" CA certificate:
>
> By "sub roots" I presume you mean subordinate CAs. At present there are 
> two subordinate CAs under the "COMODO Certification Authority" root: 
> "COMODO EV SSL CA" and "COMODO EV SGC CA". These two subordinates are 
> the issuing CAs for end entity certs.
>   
This seems to confirm what you claim, but in this case the entry at 
http://www.mozilla.org/projects/security/certs/pending/#Comodo (see the 
last section) isn't correct (which was confirmed by you btw.). It states 
under type "DV, IV/OV, EV".

As I understand, there are only EV intermediate CA certificates under 
this root and the mentioning of DV,IV etc is wrong perhaps?

Additionally it might be useful if questions relating to your CA 
operations can be directed directly to you at this list?

-- 
Regards 
 
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390
 

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Comodo request for EV-enabling 3 existing roots

[Eddy Nigg (StartCom Ltd.)]

Frank Hecker:
> Eddy Nigg (StartCom Ltd.) wrote:
>   
>> I working up my backlogat first I thought this to be a good idea to 
>> split the request up, but on the other hand I wonder if it's really that 
>> good. Because we might see all requests in their context maybe...not sure.
>> 
>
> For some information on context please see below.
>   
Frank, first of all thank you for your effort of this interesting reply. 
There isn't much to add for me, as I agree with most/all you also said 
in it what Mozilla concerns. All the rest are facts you updated us 
about...But I'm going to reply to the post Rob from Comodo instead...

-- 
Regards 
 
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390
 

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Comodo request for EV-enabling 3 existing roots

[Rob Stradling]

Frank, thanks for your detailed explanation.  I concur with everything you've 
said, but I'd just like to add a couple of additional comments (inline) in 
reply to Eddy...

On Wednesday 12 March 2008, Frank Hecker wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
> > I working up my backlogat first I thought this to be a good idea to
> > split the request up, but on the other hand I wonder if it's really that
> > good. Because we might see all requests in their context maybe...not
> > sure.
>
> For some information on context please see below.
>
> > Just what somewhat annoys me, is that all this roots issue all types of
> > certificates from DV to EV,

The Root Certificate Programs of many software providers place restrictions on 
the total number of Root CA Certificates that they will accept from any one 
CA organization.

In the case of Microsoft's Root Certificate Program: "Up to three roots per CA 
can be accepted into the Program because each additional root negatively 
impacts users by increasing download time".
http://www.microsoft.com/technet/archive/security/news/rootcert.mspx?mfr=true

Also, we have encountered a number of Root Programs for mobile/embedded 
devices that restrict the number of roots to only 1 or 2 per CA.

Given that we want to embed the same Root Certificate(s) in all platforms (to 
avoid, if at all possible, the need for further problem-prone 
cross-certification!), we really need to have generic (rather than 
purpose-specific) trust anchors.

> > sometimes even their intermediate CAs do that...

For the record, I can assure you that Comodo never issue DV and EV certs from 
the same Intermediate CA.

Having just said that, there is one exception I can think of: to help Mozilla 
do technical testing, we recently issued an EV certificate and a non-EV 
Certificate directly from each of our Roots.

> > it's not really an issue but makes it somehow unclear, plus if 
> > we'd want to limit this or other CAs in some way it makes it difficult
> > if not impossible.

> As I understand it, the original plan (as worked out within the CA
> Browser Forum) was for EV not to require the creation of new roots.
> Instead the certificatePolicies extension was to be used to limit how
> and where EV certificates could be issued within existing CA
> hierarchies. This plan is reflected in section 7 of the 1.0 EV
> guidelines (pages 11-12).
>
> Under this plan, my understanding is that the original intent of Comodo,
> VeriSign, and other CAs was simply to mark their existing roots for EV
> use, with an associated EV policy OID (or OIDs). Then they could simply
> create new EV-specific subordinate CAs, and permit those subordinate CAs
>   to issue EV certificates by putting the certificatePolicies extension
> with the appropriate EV OID on the subordinate CAs' CA certificates.
>
> Unfortunately this simple plan had to be abandoned because it didn't
> work properly with EV-aware versions of IE on Windows. It was OK for
> Windows Vista, because Vista by default doesn't include any CA certs
> other than Microsoft's own certs. Thus when IE on Vista went to a new EV
> site, Windows would realize it needed the root CA cert, would go out to
> Microsoft to fetch it, and would get an up-to-date copy with all the
> associated EV metadata.
>
> However although Windows XP can also fetch new roots in this way, XP
> already had copies of legacy roots from Comodo, VeriSign, etc., and
> hence would use the out-of-date root data that didn't include the EV
> OIDs. Hence Comodo, VeriSign, etc., had to create new EV-specific roots,
> so XP would be forced to go out and get the new roots (and the
> associated EV metadata) instead of relying on its pre-loaded data.
>
> But creating new EV-specific roots in turn meant that old versions of
> browsers (including Firefox) wouldn't recognize sites with EV certs as
> being valid SSL sites at all, since they wouldn't recognize the new
> roots. So Comodo, VeriSign, etc., also implemented schemes whereby the
> new EV roots would be cross-signed by legacy roots, and EV SSL sites
> would send cert chains that include a CA cert corresponding to the new
> EV roots, but chain up to the old roots.
>
> Finally, the cross-signing scheme meant that an EV-aware browser (or OS)
>   could now see two possible paths to a trust anchor: a path terminating
> at the new EV root, and a path terminating at a legacy root. In order to
> absolutely guarantee that EV-aware browsers recognize EV certs in all
> cases, both the new EV root and the legacy root have to be marked with
> the EV metadata. This compensates for any indeterminancy in the
> underlying certificate path processing code that might cause browsers to
> sometimes use the legacy root as a trust anchor and in other cases to
> use the new EV-specific root as a trust anchor.
>
> So, to summarize the situation as I understand it: Adding new EV roots
> was basically a hack to get IE7 on XP to treat EV certs properly.
> Cross-signing using legacy roo

Re: VeriSign request for EV root inclusion

[Frank Hecker]

Frank Hecker wrote:
> VeriSign has applied to add a new EV root CA certificate to the Mozilla 
> root store, as documented in the following bug:
> 
>   https://bugzilla.mozilla.org/show_bug.cgi?id=402947

> I have evaluated their request, as per the mozilla.org CA certificate 
> policy:
> 
>   http://www.mozilla.org/projects/security/certs/policy/
> 
> and plan to officially approve this request after a public comment period.

The comment period has ended, and there are no outstanding issues and 
questions, so I'm formally approving the VeriSign request to add the 
Class 3 Public Primary CA - G5 root to NSS and to mark it as suitable 
for EV use. I've filed bug 422918 against NSS and bug 422921 against PSM 
to make the actual code changes required.

   https://bugzilla.mozilla.org/show_bug.cgi?id=422918
   https://bugzilla.mozilla.org/show_bug.cgi?id=422921

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto