<p dir="ltr">I'm making no statement of support at all, but I feel the current wording of your proposal effectively does that, in its broad leeway for a CA to put arbitrary-but-domain-shaped data in there, and I'm trying to understand the implications.</p>
<div class="gmail_quote">On May 22, 2013 10:03 PM, "Jeremy Rowley" <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry Ryan, are you suggesting removing 9.2.3 from the BRs and letting it<br>
fall under the catch-all requirements of Section 9.2.7? I'm okay with that<br>
as well.<br>
<br>
Jeremy<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On<br>
Behalf Of Ryan Sleevi<br>
Sent: Wednesday, May 22, 2013 7:08 PM<br>
To: jeremy rowley<br>
Cc: CABFPub<br>
Subject: Re: [cabfpub] Section 9.2.3 modification<br>
<br>
RFC 2247 is exactly why I tried to clarify the language.<br>
<br>
It has caused headache for an inordinate amount of implementations, in my<br>
experience.<br>
<br>
If you're going to present the DC as a "validated" field, then it should be<br>
a field that is at least internally consistent. Both RFC<br>
2247 and the current language leave it entirely ambiguous on how that field<br>
is encoded.<br>
<br>
For example, it would be, under 'naieve' terms, fully legal under both RFC<br>
2247 and the current BRs to encode the DC as a single SEQUENCE, in which<br>
every domainComponent is part of ONE SET<br>
<br>
eg:<br>
SEQUENCE -- RDNSequence<br>
SET<br>
SEQUENCE<br>
"0.9.2342.19200300.100.1.25"<br>
"test"<br>
SEQUENCE<br>
"0.9.2342.19200300.100.1.25"<br>
"mysite"<br>
SEQUENCE<br>
"0.9.2342.19200300.100.1.25"<br>
"example"<br>
<br>
Which has all the appearances as being correct, but on a structural level,<br>
is equivalent to a cert that is valid within three different naming<br>
contexts, ALL equal in the hierarchy<br>
<br>
DC=test<br>
DC=mysite<br>
DC=example<br>
<br>
Or 'stringified' as EITHER "DC=test+DC=mysite+DC=example" OR<br>
"DC=example+DC=mysite+DC=test" OR "DC=example+DC=test+DC=mysite".<br>
<br>
These are all real algorithms that I've seen out there.<br>
<br>
On the topic of IGTF certificates, I think it's important to consider that<br>
the goal of the Baseline Requirements is to establish a set of baselines for<br>
trust in the information presented within a "subject", which this proposal<br>
specifically opens up to allow a broader set of information to satisfy<br>
another group's needs.<br>
<br>
The most important issue with the DC field is the same that exists with the<br>
CN field - it's a "domain shaped" field that may be misleading. Consider the<br>
CN field - which in a well-behaved implementation (eg: all the browsers<br>
participating in this forum) is ignored when a subjectAlternativeName is<br>
present - which is always true for BR certs. The BRs require that it contain<br>
an IP / FQDN present in the SAN - that is, it doesn't contain anything else,<br>
particularly anything "domain shaped".<br>
<br>
On some degree, I think it's reasonable to see the "domainComponent"<br>
field as similar to this. I'd be interested if there's a compelling argument<br>
against this, and that this is more akin to section 9.2.7.<br>
<br>
<br>
On Wed, May 22, 2013 at 5:50 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>><br>
wrote:<br>
> The certificates do not indicate the subject per se. They are part of<br>
> the subject in that the DC is domain for the community of interest,<br>
> but the domain in the DC fields is not typically controlled by the<br>
> subject. In the example certs I provided, the DC varies. I'll need to<br>
> do further research, but I believe these fields are an important part<br>
> on how the IGTF LDAP directory works (per RFC2247).<br>
><br>
> I can't speak for other CAs, but in our grid certs, we use the<br>
> DigICert domain (since we are acting as the RA for each community).<br>
> We don't need to contact anyone since we already know we control the<br>
> domain. For other entities, the most common one I've seen and know of<br>
> is Terena, where the DC specifies a Terena controlled domain. I<br>
> imagine the domain listed in the DC is verified in a typical BR fashion.<br>
><br>
> As far as usability, the practical effect of the BRs on this area is<br>
> to create a conflict with another community that has been using the DC<br>
> field for control purposes for a long time. The conflict is<br>
> unnecessary since browsers aren't currently using the DC field. The<br>
> practical effect is to drive community members away from publicly<br>
> trusted certificates and create headaches with managing multiple<br>
certificates on the same device.<br>
><br>
> The original language for the rule originated from RFC2247 which says<br>
> " As with a domain name, the most significant component, closest to<br>
> the root of the namespace, is written last." Instead of re-writing the<br>
> rules, I think it would be more accurate to simply tie the DC field to<br>
> RFC2247. I can see the concern about making sure the domain is<br>
> authorized, but the only requirement in the BRs to include a<br>
> certificate is verification under Section 11.1. I don't think we<br>
> should deviate on that for that simply because this is the DC field<br>
instead of the subjectAltName extension.<br>
><br>
> How about the following:<br>
> 9.2.3 Subject Domain Component Field<br>
> Certificate Field: subject:domainComponent (OID<br>
> 0.9.2342.19200300.100.1.25)<br>
> Required/Optional: Optional.<br>
> Contents: If present, this field MUST comply with RFC 2247 and<br>
> contain components of a Domain Name that is verified pursuant to Section<br>
11.1.<br>
><br>
> Thanks,<br>
> Jeremy<br>
><br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]<br>
> On Behalf Of Ryan Sleevi<br>
> Sent: Wednesday, May 22, 2013 6:00 PM<br>
> To: jeremy rowley<br>
> Cc: CABFPub<br>
> Subject: Re: [cabfpub] Section 9.2.3 modification<br>
><br>
> On Wed, May 22, 2013 at 4:32 PM, Jeremy Rowley<br>
> <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>><br>
> wrote:<br>
>> Hi everyone,<br>
>><br>
>><br>
>><br>
>> As mentioned there is an incompatibility between the Baseline<br>
>> Requirements and other industry groups on what information should be<br>
>> included in a Domain Component Field. I modified the motion slightly<br>
>> based on Ryan Sleevi's comments during last week's phone call.<br>
>> Please let me know if you are willing to endorse or have suggestions.<br>
>><br>
>><br>
>><br>
>> ---Motion Begins----<br>
>><br>
>> Replace Section 9.2.3<br>
>><br>
>><br>
>><br>
>> Certificate Field: subject:domainComponent (OID<br>
>> 0.9.2342.19200300.100.1.25)<br>
>><br>
>> Required/Optional: Optional.<br>
>><br>
>> Contents: If present, this field MUST contain all components of the<br>
>> subject's Registered Domain Name in ordered sequence, with the most<br>
>> significant component, closest to the root of the namespace, written<br>
last.<br>
>><br>
>><br>
>><br>
>> With the following:<br>
>><br>
>><br>
>><br>
>> 9.2.3 Subject Domain Component Field<br>
>><br>
>> Certificate Field: subject:domainComponent (OID<br>
>> 0.9.2342.19200300.100.1.25)<br>
>><br>
>> Required/Optional: Optional.<br>
>><br>
>> Contents: If present, this field MUST contain components of a Domain<br>
>> Name verified under Section 11.1.1 in ordered sequence, with the most<br>
>> significant component, closest to the root of the namespace, written<br>
>> last. The CA SHALL implement and follow a process that prevents a<br>
>> Domain Component field from including information if the CA is<br>
>> unaware of the logical association between the Domain Component field<br>
>> information and the Certificate's Subject.<br>
>><br>
>><br>
>><br>
>> -----Motion Ends-----<br>
>><br>
><br>
> Jeremy<br>
><br>
> In looking at the original language - which your proposal refines - it<br>
> actually strikes me as a bit odd.<br>
><br>
> Namely: "with the most significant component, closest to the root of<br>
> the namespace, written last"<br>
><br>
> I'm guessing this is the classic "hierarchy of name components"<br>
> problem that has bit many an implementation, due to questions about<br>
> the correct-way to stringify an X.500 name.<br>
><br>
> Recall that the ASN.1 structure for a Name is (roughly):<br>
> SEQUENCE -- RDNSequence<br>
> SET -- RelativeDistinguishedName<br>
> SEQUENCE -- AttributeTypeAndValue<br>
> OBJECT IDENTIFIER -- AttributeType<br>
> ANY -- AttributeValue<br>
><br>
> Because SEQUENCEs are ordered, but SETs are not, I would expect that<br>
> the proper form of any name using a DomainComponent field to follow a<br>
> meaningful<br>
> (hierarchical) ordering. The current language attempts to do so, but<br>
> in a way that I think is both wrong and misleading - by suggesting<br>
"written last"<br>
> - but in fact means *present first* (since there is no agreed upon<br>
> stringization)<br>
><br>
> That is<br>
> SEQUENCE -- RDNSequence<br>
> SET -- RelativeDistinguishedName<br>
> SEQUENCE<br>
> "0.9.2342.19200300.100.1.25"<br>
> "example"<br>
> SET -- RelativeDistinguishedName<br>
> SEQUENCE<br>
> "0.9.2342.19200300.100.1.25"<br>
> "mysite"<br>
> SET -- RelativeDistinguishedName<br>
> SEQUENCE<br>
> "0.9.2342.19200300.100.1.25"<br>
> "test"<br>
><br>
> For the domain "test.mysite.example"<br>
><br>
> Suggested wording:<br>
> If present, values of this field MUST be structured as followed:<br>
> - Each instance of a RelativeDistinguishedName must contain only a<br>
> single AttributeType of domainComponent, OID ....<br>
> - Each RelativeDistinguishedName containing a domainComponent must<br>
> form an ordered sequence that is encoded in order of the most<br>
> significant component, closest to the root of the namespace, to the least<br>
significant component.<br>
><br>
> Note that I'm trying to eliminate any reference to how it "is<br>
> written", and focus solely on how it is encoded.<br>
><br>
><br>
> On the topic of your proposal, I'm confused. Your example of the IGTF<br>
> document indicates that the DC portion of the subject indicates "a<br>
> responsible community or verifier". That is, it does not indicate the<br>
> subject, per-se.<br>
><br>
> So when verifying the domain according to Section 11.1.1, who is being<br>
> contacted, if NOT the Applicant? How does a CA obtain such<br>
> information? Etc<br>
><br>
> Additionally, I'm incredibly nervous about such broad language as "the<br>
> logical association between the Domain Component field information and<br>
> the Certificate's subject". If I did business with a firm at some<br>
> point in the past, does that mean they have "a logical association"<br>
> with a domain I may operate?<br>
><br>
> I realize that this is information that browsers do not (or SHOULD<br>
> not. I certainly hope no implementations are using it...) use for<br>
> domain validation<br>
> (eg: RFC 6125), but when we talk about the overall SSL ecosystem, such<br>
> a proposal would prevent the DC field from ever being useful for any<br>
> form of programatic enforcement. Is that acceptable? I'm not sure...<br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</blockquote></div>