[cabfpub] Section 9.2.3 modification

Ryan Sleevi sleevi at google.com
Wed May 22 22:33:37 MST 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130522/171f12e8/attachment-0001.html 


More information about the Public mailing list