[cabfpub] Section 9.2.3 modification

[Jeremy Rowley]

Since my position is that the applicant/subscriber is essentially unknown
for a DV Cert, I still disagree with your analysis regarding the subject of
a DV certificate.  However,  I do agree that Geoff's proposed language is
more clear and precise.  Therefore, my new proposed motion is as follows:

---Motion Begins----

Replace Section 9.2.3 with the following:

Certificate Field:  subject:domainComponent (OID 0.9.2342.19200300.100.1.25)
Required/Optional:  Optional.  
Contents: If present, this field MUST contain a label from a Domain Name.
The domainComponent fields for each Domain Name MUST be in a single ordered
sequence containing all labels from the Domain name.  The labels MUST be
encoded in the reverse order to the on-wire representation of domain names
in the DNS protocol, so that the label closest to the root is encoded first.
The CA MUST ensure that the certificate is issued with the consent of, and
according to procedures established by, the owner of each Domain Name.

-----Motion Ends-----

Goeff - since this is your language, would you care to endorse?

Jeremy


-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ryan Sleevi
Sent: Thursday, May 23, 2013 1:44 PM
To: jeremy rowley
Cc: CABFPub
Subject: Re: [cabfpub] Section 9.2.3 modification

On Thu, May 23, 2013 at 12:00 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:
>> 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.

Respectfully, I'm going to have to disagree here.

The Subject field (that is, the X.509v3 subject field of the
TBSCertificate) should identify the logical Subject.

If you want to identify multiple subjects, then a field like subjectAltName
is precisely for that, and the BRs specifically call that out. But I don't
think you should be conflating the two, or using the Subject field to
represent multiple distinct identities. Nor do I take the language of the
BRs to be supporting your argument - that is, that the Subject can contain
multiple distinct operational identities.

The case of subjectAltName / multiple names that represent different
business organizations (eg: the 'shared hosting' scenario that some CA
members have such trouble with) arguably fits where the Subject identifies
the device serving these domains.

In the case of the IGTF, with the language you provided, it's clear that the
domainComponent does NOT tie to the device, but in fact ties to the
"responsible community or verifying party" - something that fits neither
into the device notion or into the broader notion of Subject esposed in the
BRs Section 4. It's an entirely different entity and purpose entirely.

The current proposal - as with a proposal to move this 9.2.7 - essentially
permits information unrelated to the subscriber to be entered into the
Subject - and I think that's a troubling notion.

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

If your position is that there is no Applicant/Subscriber when issuing DV
certs, I think that's pretty troubling.

Even for DV certs, there is an Applicant/Subscriber for said certs.
The Subject for such certs is "either the Subscriber or a device under the
control and operation of the Subscriber".

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

Even in the case of a DV cert, the CA is required to confirm that the
Applicant is authorized for the domain for which they're requesting
inclusion - with the Subject being the device that services these
organizationally-distinct domains (eg: the shared hosting provider).

Removing 9.2.3 entirely has the effective behaviour of allowing a CA to
indicate domainComponents for a name independent of the Applicant -
troubling.

A proposed change to require 9.2.3 "only" adhere to 11.1.1 fails to meet
your stated objective, because 11.1.1 requires "the Applicant either is the
Domain Name Registrant or has control over the FQDN", whereas the IGTF
purposes indicates that it may be "the verifying party" - eg: *not* the
applicant, nor something the applicant has control over. This is what Geoff
pointed out.

To be clear, I'm not stating a direct opposition to finding a suitable
solution for the IGTF's needs - but I'm trying to highlight the slippery
slope of interpretation that arises from the proposal, and trying to make
sure that there are not unintended or misleading consequences. Language that
requires a "common understanding" is troubling, because as we've seen with
the variety of incidents in the past years, not every publicly trusted CA
reaches the same "common understanding".
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public