[cabfpub] Intermediate certificate names

Ryan Sleevi sleevi at google.com
Wed Mar 11 05:45:11 UTC 2015


Reposting for Peter
On Mar 10, 2015 10:39 PM, "Peter Bowen" <pzbowen at gmail.com> wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150310/0e474174/attachment-0003.html>


More information about the Public mailing list