[cabfpub] Intermediate certificate names

Wed Mar 11 05:00:19 UTC 2015

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:

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:
- Intro updated to say that the Issuer information must match the subject DN of the issuing CA. 
- Deleted all subsections.

Updated 9.2 for editorial clarity in the following sections:
- 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.
- Moved  the definition of Common Name down one subsection where it belongs (within the Subject Distinguished Name Fields).
- Small edit to insert "only" into this statement since metadata is allowed, but the field should not be only metadata:
               Optional attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) 
                characters, and/or any other indication that the value is absent, incomplete, or not applicable.

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:

    9.2.3 Subject Information - Subordinate CA Certificates
    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.

Doug

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Jeremy Rowley
> Sent: Tuesday, March 10, 2015 3:36 PM
> To: Jeremy Rowley; Geoff Keating
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Intermediate certificate names
> 
> To clarify, current Section 9.1.1 talks only about the issuer fields.  To support
> name chaining under RFC 5280, these fields must contain the same information
> as found in the subject of the issuing cert.  This is not clear in the language.
> 
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Jeremy Rowley
> Sent: Tuesday, March 10, 2015 4:24 PM
> To: Geoff Keating
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Intermediate certificate names
> 
> That could be three different entities.
> 
> However, we realized during the discussion that the section actually mixes two
> issues: 1) information in the subject of the issuing cert and 2) information in the
> issuer field of an end-entity cert. To clarify, we're going to need to separate out
> the two issues.
> 
> -----Original Message-----
> From: Geoff Keating [mailto:geoffk at apple.com]
> Sent: Tuesday, March 10, 2015 3:39 PM
> To: Jeremy Rowley
> Cc: Rob Stradling; Erwann Abalea; public at cabforum.org
> Subject: Re: [cabfpub] Intermediate certificate names
> 
> I was speaking loosely.  The actual definition from the BRs is that the CA is "An
> organization that is responsible for the creation, issuance, revocation, and
> management of Certificates."
> 
> > On 10 Mar 2015, at 2:27 pm, Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
> >
> > Here's a realistic scenario that I think demonstrates a lot of the complication:
> > 1) CA1 signs a cert for CA2 (cross-sign)
> > 2) CA3 hosts the infrastructure for CA2 (hosting)
> > 3) RA1 does all the validation and approves issuance of the cert.
> >
> > What is the name of the intermediate and who controls the private key?
> 
> So, in this case, the organization that is *responsible* is probably CA2.  They
> oversee RA1, they have a contract with CA3.  CA1 probably won't want to be
> responsible for CA2's operations.  CA3 will say "we're just hosting, we have no
> liability for anything".
> 
> You can do this backwards, by saying that the organization named in the
> certificate is the CA and therefore is responsible; so, the real question is, as the
> CA issuing the intermediate, who do you trust to be responsible?
> 
> > -----Original Message-----
> > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Rob Stradling
> > Sent: Tuesday, March 10, 2015 3:24 PM
> > To: Geoff Keating; Erwann Abalea
> > Cc: public at cabforum.org
> > Subject: Re: [cabfpub] Intermediate certificate names
> >
> > What does it actually mean to "hold" a private key?
> >
> > http://www.merriam-webster.com/dictionary/holder says:
> > "a person who holds or owns something"
> >
> > If Bozo, Inc owns a private key but DigiCert controls it, who is the CA?
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Issuer CA update r1.doc
Type: application/msword
Size: 145920 bytes
Desc: Issuer CA update r1.doc
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150311/eb658699/attachment-0003.doc>