[cabfpub] Section 9.2.3 modification

[Ryan Sleevi]

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