<p dir="ltr">Reposting for Peter</p>
<div class="gmail_quote">On Mar 10, 2015 10:39 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">By removing 9.1, this effectively removes any requirement on the<br>
content of names in CA certificates.  Would it not make more sense to<br>
make the outline like:<br>
<br>
9.1 Subject Distinguished Name<br>
9.1.1 Issuing CA Certificates<br>
9.1.2 Subscriber Certificates<br>
9.2 Subject Alternative Names<br>
9.3 Policy Identification<br>
9.3.1 Reserved Certificate Policy Identifiers<br>
9.3.2 Root CA Certificates<br>
9.3.3 Subordinate CA Certificates<br>
9.3.4 Subscriber Certificates<br>
<br>
The current 9.1 would become 9.1.1, the current 9.2.1 becomes 9.2, and<br>
the rest of the current 9.2.* becomes 9.1.2.<br>
<br>
If the Issuing CA Certificate Subject DN requirements need updating to<br>
help ensure that there is clarity on requirements for the auditors,<br>
then those requirements show be clarified and put in 9.1.1.  These<br>
requirements should  include some language around existing names and<br>
allowance to not change the name of existing certificates, even if the<br>
identified organization no longer owns or operates the root; for<br>
example if one CA buys a certificate from another (e.g. RSA bought one<br>
of the ValiCert roots a number of years ago).<br>
<br>
Thanks,<br>
Peter<br>
<br>
On Tue, Mar 10, 2015 at 10:00 PM, Doug Beattie<br>
<<a href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.com</a>> wrote:<br>
> I've taken a shot at updating sections 9.1 (Issuer Information) and 9.2 (Subject Information) per the CA/B Forum meeting earlier today for consideration as a pre-ballot to help clarify this and to support Richard in his false audit finding:<br>
><br>
> Section 9.1 is focused on defining the content of the Issuer information fields, but since this must match the subject name of the issuing CA, this is very straightforward and the prior description was overly complex and unnecessary:<br>
> - Intro updated to say that the Issuer information must match the subject DN of the issuing CA.<br>
> - Deleted all subsections.<br>
><br>
> Updated 9.2 for editorial clarity in the following sections:<br>
> - Deleted 9.2.3 Subject Domain Component Field.  There is nothing special about this and can be covered in 9.2.2 h) "Other subject Attributes" which says all other fields must be verified by the CA.  The OID defined in the BRs is also of questionable validity.<br>
> - Moved  the definition of Common Name down one subsection where it belongs (within the Subject Distinguished Name Fields).<br>
> - Small edit to insert "only" into this statement since metadata is allowed, but the field should not be only metadata:<br>
>                Optional attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space)<br>
>                 characters, and/or any other indication that the value is absent, incomplete, or not applicable.<br>
><br>
><br>
> Note that section 9.2.5 (new section number 9.2.3) clearly specifies how the Subject DN of an issuing CA should be created and this should be sufficient to support Richard's auditors to remove the question on his audit.  It says:<br>
><br>
>     9.2.3 Subject Information - Subordinate CA Certificates<br>
>     By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificate's issuance date, all of the Subject Information was accurate.<br>
><br>
><br>
> Doug<br>
><br>
>> -----Original Message-----<br>
>> From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]<br>
>> On Behalf Of Jeremy Rowley<br>
>> Sent: Tuesday, March 10, 2015 3:36 PM<br>
>> To: Jeremy Rowley; Geoff Keating<br>
>> Cc: <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
>> Subject: Re: [cabfpub] Intermediate certificate names<br>
>><br>
>> To clarify, current Section 9.1.1 talks only about the issuer fields.  To support<br>
>> name chaining under RFC 5280, these fields must contain the same information<br>
>> as found in the subject of the issuing cert.  This is not clear in the language.<br>
>><br>
>> -----Original Message-----<br>
>> From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]<br>
>> On Behalf Of Jeremy Rowley<br>
>> Sent: Tuesday, March 10, 2015 4:24 PM<br>
>> To: Geoff Keating<br>
>> Cc: <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
>> Subject: Re: [cabfpub] Intermediate certificate names<br>
>><br>
>> That could be three different entities.<br>
>><br>
>> However, we realized during the discussion that the section actually mixes two<br>
>> issues: 1) information in the subject of the issuing cert and 2) information in the<br>
>> issuer field of an end-entity cert. To clarify, we're going to need to separate out<br>
>> the two issues.<br>
>><br>
>> -----Original Message-----<br>
>> From: Geoff Keating [mailto:<a href="mailto:geoffk@apple.com">geoffk@apple.com</a>]<br>
>> Sent: Tuesday, March 10, 2015 3:39 PM<br>
>> To: Jeremy Rowley<br>
>> Cc: Rob Stradling; Erwann Abalea; <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
>> Subject: Re: [cabfpub] Intermediate certificate names<br>
>><br>
>> I was speaking loosely.  The actual definition from the BRs is that the CA is "An<br>
>> organization that is responsible for the creation, issuance, revocation, and<br>
>> management of Certificates."<br>
>><br>
>> > On 10 Mar 2015, at 2:27 pm, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>><br>
>> wrote:<br>
>> ><br>
>> > Here's a realistic scenario that I think demonstrates a lot of the complication:<br>
>> > 1) CA1 signs a cert for CA2 (cross-sign)<br>
>> > 2) CA3 hosts the infrastructure for CA2 (hosting)<br>
>> > 3) RA1 does all the validation and approves issuance of the cert.<br>
>> ><br>
>> > What is the name of the intermediate and who controls the private key?<br>
>><br>
>> So, in this case, the organization that is *responsible* is probably CA2.  They<br>
>> oversee RA1, they have a contract with CA3.  CA1 probably won't want to be<br>
>> responsible for CA2's operations.  CA3 will say "we're just hosting, we have no<br>
>> liability for anything".<br>
>><br>
>> You can do this backwards, by saying that the organization named in the<br>
>> certificate is the CA and therefore is responsible; so, the real question is, as the<br>
>> CA issuing the intermediate, who do you trust to be responsible?<br>
>><br>
>> > -----Original Message-----<br>
>> > From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]<br>
>> On Behalf Of Rob Stradling<br>
>> > Sent: Tuesday, March 10, 2015 3:24 PM<br>
>> > To: Geoff Keating; Erwann Abalea<br>
>> > Cc: <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
>> > Subject: Re: [cabfpub] Intermediate certificate names<br>
>> ><br>
>> > What does it actually mean to "hold" a private key?<br>
>> ><br>
>> > <a href="http://www.merriam-webster.com/dictionary/holder" target="_blank">http://www.merriam-webster.com/dictionary/holder</a> says:<br>
>> > "a person who holds or owns something"<br>
>> ><br>
>> > If Bozo, Inc owns a private key but DigiCert controls it, who is the CA?<br>
>><br>
>> _______________________________________________<br>
>> Public mailing list<br>
>> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
>> <a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
>> _______________________________________________<br>
>> Public mailing list<br>
>> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
>> <a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
><br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
><br>
</blockquote></div>