Eddy Nigg (StartCom Ltd.) wrote: > Michael Ströder wrote: >> Who decided and why that EV meta data can only be added to trust anchors? >> > This is actually a valid question, since at common CA setups there is > one root and different intermediates which sign according to different > procedures. Haven't got to think about it, but if a root must be present > this would imply that most of the times the relevant intermediate CA > certificate signing EV certificates must be also included in NSS.
I'm not an expert in this by any means, but I think this is addressed by the section 7 text I referenced earlier: If a root has two subordinates, one of which issues EV certs and one of which doesn't, then the CA cert for the first subordinate includes the EV policy OID assigned to that subordinate (or, as a special case for "in house" subordinates, the "anyPolicy" OID), and NSS keeps a record of that EV policy OID as metadata with the root CA cert. So for subordinate 1 the process looks like this AFAIK: 1. NSS finds that the end entity cert has a policy OID. 2. NSS verifies that the subordinate 1 CA cert has that same policy OID (or the anyPolicy OID). 3. NSS verifies that the same policy OID is stored as (pre-loaded) metadata with the (pre-loaded) root CA cert. 4. NSS recognizes the policy OID as indicating "EV-ness" and does whatever it does to accord EV treatment to the EE cert. For subordinate 2, even though the end entity cert may have a policy OID meant to indicate EV-ness, the subordinate 2 CA lacks that policy OID (or the anyPolicy OID) and so the EE cert will fail the "EV test". So AFAICT there's no need for NSS to pre-load the subordinate 1 CA cert. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
