[cabfpub] BR Section 9.2.3 incompatability

Thu May 23 00:12:38 UTC 2013

I included some links in the previous email I forwarded.  However, the
reason boils down to the fact that they use the DC as part of the Subject's
distinguished name to indicate the community of interest to which the
certificate applies.  I'll see if I can dig up (and circulate) documentation
from the IGTF community on what they do with this information and why
exactly the RA/Issuer's domain is specified.  

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Steve Roylance
Sent: Wednesday, May 22, 2013 10:50 AM
To: Jeremy Rowley
Cc: public at cabforum.org
Subject: Re: [cabfpub] BR Section 9.2.3 incompatability

Hi Jeremy

Thanks for the examples which makes things much clearer (in terms of the
application) but not necessarily clear for relying parties understanding of
the Subject DN of a certificate.   Is there a particular link to some
background on why the IGTF chose to use the Subject DN to convey the
association links?   I'm not familiar with the background to this.  

I see no issue with Name Constraints related testing we have done for DC=

Thanks

Steve

From: Jeremy Rowley <jeremy.rowley at digicert.com>
Organization: DigiCert
Reply-To: Jeremy Rowley <jeremy.rowley at digicert.com>
Date: Wednesday, 15 May 2013 20:47
To: Steve Roylance <steve.roylance at globalsign.com>
Cc: <public at cabforum.org>
Subject: RE: [cabfpub] BR Section 9.2.3 incompatability

Attached are three examples from various CAs.  Notice that each has a DC of
the RA or CA, not the subject.  This is per the grid requirements.

Jeremy

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Steve Roylance
Sent: Saturday, May 11, 2013 5:00 AM
To: Jeremy Rowley
Cc: public at cabforum.org
Subject: Re: [cabfpub] BR Section 9.2.3 incompatability

Hi Jeremy,

In some instances, outside of SSL usage, it's necessary to use DC within
Name Constraints where AD is used as the engine to populate the Subject DN
through auto enrolment.  DC therefore offers a stable base to be able to use
Name Constraints.   Do you possibly have a couple of example certificate
Subject DN's that you could highlight good/bad examples?   I think that
would help everyones understanding of the proposal and how it addresses the
issue you'd like to solve.

Thanks.

Steve

From: Jeremy Rowley <jeremy.rowley at digicert.com>
Organization: DigiCert
Reply-To: Jeremy Rowley <jeremy.rowley at digicert.com>
Date: Friday, 10 May 2013 19:01
To: <public at cabforum.org>
Subject: [cabfpub] BR Section 9.2.3 incompatability

It's come to my attention that section 9.2.3 has a potential incompatibility
with the requirements imposed by IGTF and other similar communities.  

Section 9.2.3:

9.2.3 Subject Domain Component Field 

Certificate Field: subject:domainComponent (OID 0.9.2342.19200300.100.1.25)

Required/Optional: Optional. 

Contents: If present, this field MUST contain all components of the
subject's Registered Domain Name in ordered sequence, with the most
significant component, closest to the root of the namespace, written last.

>From  OGF GFD.125 [http://www.ogf.org/documents/GFD.125.pdf] Section 2.3.2:

To ensure uniqueness and proper delegation, the use of domainComponent (DC)
naming corresponding to a registered DNS name owned by the authority at the
beginning of the issuer and subject name RDN sequence is strongly
encouraged. In that case, the ASN.1 SEQUENCE MUST start with the
domainComponent representing the top-level domain, for example "DC=org" or
"DC=eu".

The need for this comes from the fact that identification is based on the
subject DN only. From the IGTF Federation Document:

"3.1 Management and communication of identifiers

On accreditation, a specific subject name space or set of subject name
spaces is allocated to each authority. This name space must not overlap with
any existing name space already assigned to an existing authority for any
AP, assigned by any of the regional PMAs within the International Grid Trust
Federation."

Really, it boils down to the fact that the IGTF space and others expect to
use the DC field to indicate a responsible community or verifier.
Therefore, I propose we modify Section 9.2.3. to permit issue, community,
and RA information in the DC as well as subject information. 

My proposal:

9.2.3 Subject Domain Component Field 

Certificate Field: subject:domainComponent (OID 0.9.2342.19200300.100.1.25)

Required/Optional: Optional. 

Contents: If present, this field MUST contain all components of a verified
Domain Name (such as the Domain Name of the subject, issuer, or RA) in
ordered sequence, with the most significant component, closest to the root
of the namespace, written last.

Let me know if you are interested in endorsing.

Thanks,

Jeremy

_______________________________________________ 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/20130522/6b7c7b25/attachment-0003.html>