[cabfpub] Section 9.2.3 modification
Jeremy Rowley
jeremy.rowley at digicert.com
Thu May 23 12:00:16 MST 2013
> To clarify, I'm not trying to do anything with respect to the
> requirements other than alleviate the compatibility concerns expressed
> by a separate industry group. In fact, I believe that a CA can easily
> follow the BRs and continue issuing grid certs under the current
> language. Afterall, a CA's obligation under the current guidelines is
> to verify the domain in accordance with Section 11.1. Verification of
> the domains relation to the subject is never confirmed under the BRs,
> making the "subject" modifier in Section 9.2.3 superfluous language.
This is an interesting, and arguably unfortunate, interpretation.
[JR] Not really an interpretation. Rather it's more of a result of
permitting DV certs in the BRs, as illustrated in the example below.
The BRs clearly spell out Subject in Section 4 as:
"The natural person, device, system, unit, or Legal Entity identified in a
Certificate as the Subject. The Subject is either the Subscriber or a device
under the control and operation of the Subscriber."
[JR] The device is the subject. In the current case there are two subjects.
Once named in the DC field and another in in the CN field. For a DV
Certificate that lists multiple domains in the subjectAltName field, you
have one subject for each listing really since there isn't necessarily a
logical association between the domains.
Within the same Section 4, the Applicant is:
"The natural person or Legal Entity that applies for (or seeks renewal
of) a Certificate. Once the Certificate issues, the Applicant is referred to
as the Subscriber. For Certificates issued to devices, the Applicant is the
entity that controls or operates the device named in the Certificate, even
if the device is sending the actual certificate request."
So we have a path established where Applicant == Subscriber (at issuance),
and Subscriber == Subject.
[JR] For DV certs, the applicant is never known. The Subscriber != Subject.
The Subject is only a domain name.
I don't see how you could reach a conclusion where Section 9.2.3 would
permit information other than that representing the Applicant/Subscriber to
be presented - thus I don't see how you would feel that Section 11.1 would
permit anything short of demonstration where the "Applicant either is the
Domain Name Registrant or has control over the FQDN"
[JR[ For a DV cert, I can verify a domain's inclusion in the certificate
using a Domain Authorization Letter or through an email to
administrator at example.com. is sufficient verification. If multiple domains
are included, there is not a requirement that the domains be related (and
often are not). The subject is really just the domains, meaning there are
multiple subjects within a single cert. I don't mean this to be an attack
on DV, but DV certs clearly illustrate the logical inconsistency in your
analysis. There is more assurance that the domain is tied to the subject
with an OV cert since the CA is required to verify the certificate request
and its authorization form the organization.
>
>
>
> Because the IGTF community has expressed a concern and unless someone
> has a compelling reason to leave the provision "as is", I'd still like
> to remove the requirement in 9.2.3 or at least relax the confusing
"subject" language.
> Although you might not like the vagueness in RFC 2247, it's the
> standard for using DC information in LDAP directories. I'm all for
> clarifying the RFC at IETF, but I don't think we should do so at the CAB
Forum level.
You're confusing two different standards.
The CA/Browser Forum concerns itself with the application of X.509 and the
PKI on the Internet (PKIX).
RFC 2247 concerns itself with LDAP.
[JR] Grid Certs are used on the Internet and with an LDAP. They bridge the
gap. That's why there is a potential problem in the current language.
Nominally, the two share common ancestry through X.500, but they are
different protocols entirely. The use of the LDAP string representation
algorithms for the X.500 names within an X.509v3/PKIX certificate is by no
means uncommon, but neither is it the only way to represent these names.
Regardless of this "spec quibbling", documents produced by the CA/B Forum
should be unambiguous with respect to how things should be encoded. You can
see these sorts of clarifications through the profiling of PKIX (itself a
profile of X.509) that is done within the Baseline Requirements (Appendixes
A and B, for example, in addition to Sections 9.1 - 9.6)
[JR] I actually don't have a problem with your point on this since your
proposal won't undermine the current implementations of IGTF. I'm inclined
to support the proposal Geoff Keating makes, but need to ask members of that
community before adopting his language. Are you good with his proposal? Is
it a change Google would endorse?
>
>
>
> Would you object to a motion that simply removed 9.2.3 pending further
> exploration of security concerns? Removing 9.2.3 would still prohibit
> unverified information under 9.2.7 and get rid of the extremely vague
> encoding language in the existing BRs. We can then re-insert proper
> encoding procedures once the IETF has clarified the RFC.
>
>
>
> Jeremy
>
>
>
>
>
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Ryan Sleevi
> Sent: Wednesday, May 22, 2013 11:34 PM
>
>
> To: jeremy rowley
> Cc: CABFPub
> Subject: Re: [cabfpub] Section 9.2.3 modification
>
>
>
> 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.
>
> On May 22, 2013 10:03 PM, "Jeremy Rowley" <jeremy.rowley at digicert.com>
> wrote:
>
> Sorry Ryan, are you suggesting removing 9.2.3 from the BRs and letting
> it fall under the catch-all requirements of Section 9.2.7? I'm okay
> with that as well.
>
> 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 7:08 PM
> To: jeremy rowley
> Cc: CABFPub
> Subject: Re: [cabfpub] Section 9.2.3 modification
>
> 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
>>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
More information about the Public
mailing list