[cabfpub] BR Section 9.2.3 incompatability

[Steve Roylance]

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/14172c81/attachment-0003.html>