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