<html 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"><head><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]--></head><body 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 [http://www.ogf.org/documents/GFD.125.pdf] 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></body></html>