<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 12px; font-family: Arial, sans-serif; "><div><div><div>Hi Jeremy,</div><div><br></div><div>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.</div><div><br></div><div>Thanks.</div><div><br></div><div>Steve</div><div><div><br></div><p></p></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>><br><span style="font-weight:bold">Organization: </span> DigiCert<br><span style="font-weight:bold">Reply-To: </span> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>><br><span style="font-weight:bold">Date: </span> Friday, 10 May 2013 19:01<br><span style="font-weight:bold">To: </span> <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><span style="font-weight:bold">Subject: </span> [cabfpub] BR Section 9.2.3 incompatability<br></div><div><br></div><div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri","sans-serif";}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal">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.  <o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Section 9.2.3:<o:p></o:p></p><p class="MsoNormal">9.2.3 Subject Domain Component Field <o:p></o:p></p><p class="MsoNormal">Certificate Field: subject:domainComponent (OID 0.9.2342.19200300.100.1.25)<o:p></o:p></p><p class="MsoNormal">Required/Optional: Optional. <o:p></o:p></p><p class="MsoNormal">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.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">From  OGF GFD.125 [<a href="http://www.ogf.org/documents/GFD.125.pdf">http://www.ogf.org/documents/GFD.125.pdf</a>] Section 2.3.2:<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">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”.<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">The need for this comes from the fact that identification is based on the subject DN only. From the IGTF Federation Document:<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">"3.1 Management and communication of identifiers<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">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."<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">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. <o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">My proposal:<o:p></o:p></p><p class="MsoNormal">9.2.3 Subject Domain Component Field <o:p></o:p></p><p class="MsoNormal">Certificate Field: subject:domainComponent (OID 0.9.2342.19200300.100.1.25)<o:p></o:p></p><p class="MsoNormal">Required/Optional: Optional. <o:p></o:p></p><p class="MsoNormal">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.<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">Let me know if you are interested in endorsing.<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">Thanks,<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">Jeremy<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p></div></div></div>_______________________________________________
Public mailing list
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</span></body></html>