[cabfpub] Section 9.2.3 modification

[Ryan Sleevi]

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...