<p dir="ltr">Reposting for Peter</p>
<div class="gmail_quote">On Mar 9, 2015 11:41 PM, "Peter Bowen" <<a href="mailto:pzbowen@gmail.com">pzbowen@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 9, 2015 at 10:01 PM, Jeremy Rowley<br>
<<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
> One of the discussions going on includes how CAs should name intermediates.<br>
> Right now, the BRs say that the org field of the issuer “MUST contain the<br>
> name (or abbreviation thereof), trademark, or other meaningful identifier<br>
> for the CA, provided that they accurately identify the CA. The field MUST<br>
> NOT contain a generic designation such as “Root” or “CA1”.” There is a<br>
> similar requirement for the CN field.<br>
<br>
As the BRs are worded currently, this applies to both Root and<br>
Intermediate CAs, they are both included in the definition of "Issuing<br>
CA".<br>
<br>
> We’ve heard that some auditors are interpreting this as a requirement that<br>
> the CA must be named in each intermediate.  I disagree as calling each of<br>
> our Intermediates DigiCert Intermediate 1 CA, DigiCert Intermediate 2 CA,<br>
> etc. is less useful than specifying their intended purpose or intended<br>
> beneficiary. I think the word “accurately identify the CA” leaves a question<br>
> about whether you identifying the holder of the private key or the entity<br>
> authorized to approve issuance from the intermediate (such as a separate Sub<br>
> CA).<br>
<br>
 Yes, my reading of the BRs is that the minimal name for a compliant CA is:<br>
((Country, "XX"), (Organization, "Example"), (Common Name, "Example CA"))<br>
<br>
This is based on sections 9.1.1, 9.1.3, and 9.1.4 all being required.<br>
<br>
While this seems redundant, it makes sense when you look at how<br>
browsers display issuer information.  Try visiting<br>
<a href="https://www.keypost.ch/" target="_blank">https://www.keypost.ch/</a> and <a href="https://learnable.com" target="_blank">https://learnable.com</a> to in various<br>
browsers (the former being non-EV and the latter is EV).<br>
<br>
IE: Shows the "Friendly Name" of the root CA<br>
Firefox: Shows Issuer Organization attribute<br>
Chrome: Shows Issuer Common Name<br>
<br>
> One suggestion that someone made is to include a marker in the cert that<br>
> basically says “the holder of the private key is not the subject of the cert<br>
> but is the issuer”.  This would have the added benefit of clearing up how<br>
> many CAs are actually out there.<br>
<br>
RFC 3647 mentions both "Certificate Manufacturing Authorities" and<br>
"Repository Service Providers", which are different from certification<br>
authorities.  I've also seen Certification Status Authority (runs the<br>
OCSP responders) broken out in some CPs and CPSes.<br>
<br>
If one accepts that the CA, CMA, and RSP may all be different<br>
entities, then it would<br>
seem that the CA CA is the entity that is audited and has a CPS and<br>
contracts with the others for services.  In the example you mentioned,<br>
the holder of the private key would be the CMA, and the subject of the<br>
cert would be the CA.<br>
<br>
Where do these relationships need to be disclosed?  Good question.  As<br>
it stands today, I think it only requires disclosure to the parties<br>
and to the auditors.  No public disclosure is required as long as the<br>
CA says they are taking overall responsibility for certificates issued<br>
in their name.  In that case the Issuer should reasonably be the CA,<br>
even if they don't have physical possession of the private key.<br>
<br>
Thanks,<br>
Peter<br>
</blockquote></div>