[cabfpub] Intermediate certificate names

Wed Mar 11 07:38:33 MST 2015

Hi Peter,

I don’t think we've removed the requirements for what goes into CA certificates.  Attempting to describe what goes into the issuer field is not relevant, it MUST be the same as the Subject DN of the issuing CA, there are no other options.  Given this, a good description of what can go into the subject DN of certificates (CAs and SSL) is a good idea.  But, do we need to go further than what is documented today (CAs must follow their CPS when issuing subordinate CAs)?  This task was primarily driven by a recent audit finding for one CA which the other CAs do not believe is a finding, so clarifying the misleading section seems like the best immediate solution.  I think the auditor will reverse his findings based on this update (which is the goal of this proposed ballot).

Doug

> -----Original Message-----
> From: Peter Bowen [mailto:pzbowen at gmail.com]
> Sent: Tuesday, March 10, 2015 10:40 PM
> To: Doug Beattie; Ryan Sleevi
> Cc: Jeremy Rowley; Geoff Keating; public at cabforum.org
> Subject: Re: [cabfpub] Intermediate certificate names
> 
> By removing 9.1, this effectively removes any requirement on the content of
> names in CA certificates.  Would it not make more sense to make the outline
> like:
> 
> 9.1 Subject Distinguished Name
> 9.1.1 Issuing CA Certificates
> 9.1.2 Subscriber Certificates
> 9.2 Subject Alternative Names
> 9.3 Policy Identification
> 9.3.1 Reserved Certificate Policy Identifiers
> 9.3.2 Root CA Certificates
> 9.3.3 Subordinate CA Certificates
> 9.3.4 Subscriber Certificates
> 
> The current 9.1 would become 9.1.1, the current 9.2.1 becomes 9.2, and the rest
> of the current 9.2.* becomes 9.1.2.
> 
> If the Issuing CA Certificate Subject DN requirements need updating to help
> ensure that there is clarity on requirements for the auditors, then those
> requirements show be clarified and put in 9.1.1.  These requirements should
> include some language around existing names and allowance to not change the
> name of existing certificates, even if the identified organization no longer owns
> or operates the root; for example if one CA buys a certificate from another (e.g.
> RSA bought one of the ValiCert roots a number of years ago).
> 
> Thanks,
> Peter
> 
> On Tue, Mar 10, 2015 at 10:00 PM, Doug Beattie
> <doug.beattie at globalsign.com> wrote:
> > 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
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> >