[cabf_validation] Using 3.2.2.4.2/.3 for future domains
Dimitris Zacharopoulos
jimmy at it.auth.gr
Fri Mar 16 00:35:32 MST 2018
From the Validation WG Summit notes:
--- BEGIN QUOTE ---
All information in the Registrant Information (email, phone, postal
address) is treated as "Authorized Representative". Even if the Contact
Person is "IT Center", a call to this number and a dialog like the
following should suffice for the verification and authorization.
- CA: "I need to reach the IT Center to verify a Certificate Request"
- Domain Owner: "Yes you have reached the IT Center"
- CA: "We have received a Public Key (blah blah, hash of the key) for
Domain example.com. Can you confirm the request and authorize issuance?"
- Domain Owner: "Yes"
That's all. Similar to email aliases where we don't know the exact
Natural Persons in the recipient list, the same applies to the telephone
number or if using the postal address.
...
...
The only "true" source of information to be treated as "Valid" is the
WHOIS (or Registrar/Registry information). This is true because the
Domain Owner makes sure that the information listed in the Registration
Entry is accurate and dependable.
To summarize (Dimitris):
- CAs must treat the Applicant as hostile.
- CAs must trust the Domain Registrant information as the only accurate
information related to the Domain.
- CAs must treat the Domain Contact information as a way to contact the
Authorized Representative that will approve the Request.
- If the Registrant information in the WHOIS data by the Registrar is
one-to-one with Organizations in a particular jurisdiction (as it
happens for some ccTLDs), it is a reliable method to establish ownership
for the Domain.
- By using the Organization's "Registration Number" in the Domain
Registrant information for a particular Domain, the CA can find
"Authorized Representative" for that Organization by looking up
Qualified Information Sources such as National Company Registries to
contact the Domain Owner.
- Since this is not a globally enforced requirement for Registrars, a
possible improvement for this method to the level of assurance of
methods 2, 3, 4, would be to require the Domain Owner to list
Registration Number, Jurisdiction of Incorporation and address (as
required for EV) IN THE DOMAIN REGISTRANT record. Therefore, this
validation method would ONLY BE USED if an unambiguous representation of
the Domain Owner was included in the Domain Registrant information. The
CA would then need to contact the Domain Owner by using QGIS/QIIS/QTIS
by using the Registration Number and Jurisdiction of Incorporation
(one-to-one mapping with the Domain Owner) and use this information to
contact the "Authorized Representative". This is an auditable criteria
as CAs that use this method to validate domains will need to prove to
their auditors how they ensure the one-to-one mapping between the Domain
and the Domain Owner.
--- END QUOTE ---
While I think adding uniquely identifiable information in the WHOIS
records is an improvement to the existing method 1 and protects against
the attacks we discussed in Herndon, Peter proposed something new that
could be introduced as a new method. Instead of relying only to the name
"Stripe Inc.", let's match all contact information records to establish
the Domain Owner.
Whois record for domain example.com:
Domain Name: EXAMPLE.COM
Registrant Name: IT Department
Registrant Organization: EXAMPLE LLC
Registrant Street: 1234 my address,
Registrant City: My city
Registrant State/Province: CA
Registrant Postal Code: 1234
Registrant Country: US
Registrant Phone: +123456
Registrant Phone Ext:
Registrant Fax: +123456
Registrant Fax Ext:
Registrant Email: emailaddress at example.com
The CA uses the WHOIS information of example.com to contact the
Authorized Representative (using phone, email, mailing address mentioned
in the whois record).
Now, consider an Applicant that requests a Certificate for example2.com.
The Whois record for example2.com looks exactly the same as example.com.
Domain Name: EXAMPLE2.COM
Registrant Name: IT Department
Registrant Organization: EXAMPLE LLC
Registrant Street: 1234 my address,
Registrant City: My city
Registrant State/Province: CA
Registrant Postal Code: 1234
Registrant Country: US
Registrant Phone: +123456
Registrant Phone Ext:
Registrant Fax: +123456
Registrant Fax Ext:
Registrant Email: emailaddress at example.com
We can reasonably assume that the Domain Owners of example.com and
example2.com are the same. I see no reason for an
organization/individual that seriously wants to properly protect/control
their Domain, to include bogus information in the Registrant records.
Taking this one step further, once we've established Domain Validation
by using WHOIS information to contact the Domain Owner (phone, email,
mailing address), if we do ADDITIONAL verification based on 3.2.5 to
establish another Applicant Representative based on a QIIS (as Peter
suggests for large organizations that have a central team that manages
certificates for the whole organization), we could add a new email
contact address (e.g. "certificate-authorizations at example.com") to be
the Authorized Representative for EXAMPLE LLC.
Since we reasonably established that example.com and example2.com have
the same Domain Owner (since whois contact information for both domains
are the same in all aspects), this means that the CA could use
"certificate-authorizations at example.com" as an Authorized Representative
contact for example2.com.
We are not saying CAs should automatically issue a certificate for
example2.com to an unknown Applicant. In the scenario I just described,
an Applicant for example2.com would need to positively respond to an
Authorization e-mail sent to "certificate-authorizations at example.com"
which looks reasonably safe.
Dimitris.
On 16/3/2018 5:13 πμ, Ryan Sleevi via Validation wrote:
> Hi Doug,
>
> It looks like the quoting configuration in your mail client may be
> messed up. It's rather hard to notice your replies, and certainly the
> archives have trouble with them. It may be worth looking into.
> Hopefully my inline replies below will fare better.
>
> On Thu, Mar 15, 2018 at 4:28 PM, Doug Beattie
> <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com>> wrote:
>
> *From:*Validation [mailto:validation-bounces at cabforum.org
> <mailto:validation-bounces at cabforum.org>] *On Behalf Of *Peter
> Bowen via Validation
> *Sent:* Thursday, March 15, 2018 12:52 PM
> *To:* Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com>>
> *Cc:* CA/Browser Forum Validation WG List <validation at cabforum.org
> <mailto:validation at cabforum.org>>
> *Subject:* Re: [cabf_validation] Using 3.2.2.4.2/.3 for future domains
>
> On Mar 15, 2018, at 9:37 AM, Ryan Sleevi <sleevi at google.com
> <mailto:sleevi at google.com>> wrote:
>
> On Thu, Mar 15, 2018 at 12:28 PM, Peter Bowen <pzb at amzn.com
> <mailto:pzb at amzn.com>> wrote:
>
> From the discussions of CA use cases where they were using
> 3.2.2.4.1, it seems that we might be able to cover a
> number of these by clarifying 3.2.2.4.2/.3.
>
> Specifically, the BRs currently say:
>
> "Each email, fax, SMS, or postal mail MAY confirm control
> of multiple Authorization Domain Names. […] MUST be sent
> to an email address, fax/SMS number, or postal mail
> address identified as a Domain Contact.”
>
> "Each phone call SHALL be made to a single number and MAY
> confirm control of multiple FQDNs, provided that the phone
> number is identified by the Domain Registrar as a valid
> contact method for every Base Domain Name being verified
> using the phone call"
>
> What is unclear is whether an an email, fax, SMS, postal
> mail, or phone call MAY be used to confirm approval for an
> unbounded set of domains names which have that method as a
> contact method. For example, can a CA email
> hostmaster at example.com <mailto:hostmaster at example.com> and
> say “Will you approve Bob to get a certificate for _any_
> domain which has hostmaster at example.com
> <mailto:hostmaster at example.com> as a Domain Contact,
> including domains not yet registered but which are
> registered in the future with hostmaster at example.com
> <mailto:hostmaster at example.com> as a Domain Contact?”
> This authorization is subject the aging requirements
> already in the BRs.
>
> Yes, the intent is that if you send an email to
> hostmaster at example.com <mailto:hostmaster at example.com> and
> ask them if they approve issuance for example.com
> <http://example.com>, and if they further approve issuance
> for future domains with a who-is contact listed as
> hostmaster at example.com <mailto:hostmaster at example.com>,
> this would be approval for issuance for domains that have
> not been provided to the CA yet, or perhaps for domains
> that are not yet registered. Yes, this authorization is
> subject to the aging requirements.
>
>
> If this is allowed, it would seem to cover the use case of
> adding domains to an existing applicant/subscriber account
> without requiring a new communication with the domain
> contact for each domain. This was the primary use case
> that I heard for 3.2.2.4.1 (1) & (2).
>
> I suppose this yet again depends on the answer to the question
> of what are we trying to validate?
>
> I think this would be a net-negative for security and a
> problematic interpretation, if authorization for 'example.com
> <http://example.com/>' could be interpreted as future
> authorization (for up to 825 days) for 'example.net
> <http://example.net/>'. I understand some CAs would like this.
> I think they're wrong and it's insecure, and not what domain
> holders would or should expect.
>
> The approval to authorize issuance under example.net
> <http://example.net> would only be done if they expressly said
> they wanted approval of new domains. There are some domain
> owners that would like this model, but I also agree there are
> some that won’t. They don’t need to provide this approval.
>
>
> The "problem" with this model is that you're effectively relying on
> the Applicant over the Domain Owner. As discussed in Reston, the
> presumption has to be the Applicant is an Attacker and the Domain
> Holder is the Defender. Hopefully, the alliterative association will
> help CAs internalize this threat model, since it's so key.
>
> In an ideal model, the flow is that you validate the Applicant is
> authorized to assert Public Key X for Domain Y in Certificate A as a
> hermetic, wholly self-contained step. If you also want to assert
> Public Key X for Domain Z, that's effectively a new process.
> 3.2.2.4.2/.3/.4 allow you to coalesce that validation across Domains,
> and 4.2.1 allows you to amortize/coalesce that validation across
> Public Keys and Certificates - that is, reusing the Domain
> Authorization for multiple distinct certificates/public keys.
>
> During the discussion of 4.2.1, it's clear that some CAs view the
> steps as further segmented - namely, that you validate the Applicant
> is authorized (for any public key) for Domain Y as a distinct step,
> and then later they can provide the public key. This is the "Do the
> validation before there's a CSR" discussion - namely, the Applicant
> saying "I will request a certificate for Y and Z" without providing
> the public key X yet in a CSR.
>
> The challenge with 3.2.2.4.1 (and this model) is that it subverts the
> notion further, by treating the Applicant as a reusable entity that
> doesn't have to be validated across domains. Namely, once you've
> validated the Applicant once, they can reuse this across multiple
> domains. As we discussed, this creates serious challenges - the notion
> of validating the Applicant as "Stripe Inc (Kentucky)" is great, and
> may allow you to validate the issuance for https://stripe.ian.sh , but
> you certainly don't want Ian to be able to then request a certificate
> for "https://www.stripe.com" simply because you see a substring match
> for "Stripe" in the (previously validated) applicant identity of
> Stripe and the whois information expressed.
>
> The proposal made in Reston seemed to hinge around the notion that
> "Imagine we could unambiguously determine, from the DNS information,
> the exact legal identity" - that is, that it would require, *at
> minimum*, all of the information within an EV certificate (since we
> claim that's sufficient to disambiguate legal identity). We discussed,
> on a per-TLD basis (that is, no CA interpretation/flexibility
> permitted) alternative requirements on a per-TLD basis - for example,
> for .no, allowing the registration number expressed in a .no domain
> registration to serve as an unambiguous key, since it ties back to the
> national registry.
>
> This, of course, would still be insecure - for example, it would allow
> any Affiliate of Alphabet (which is a wide portfolio of companies) to
> obtain any certificate for any other Alphabet property - so during the
> Reston discussions, it was further refined to be an "exact" match - no
> affiliations permitted.
>
> If we imagine that system, with its conditions, my understanding of
> the current proposal is that once we've validated the Identity I for
> Domain Y for Applicant-Attacker A, if we then go look up Domain Z, and
> see it also matches Identity I, can we allow the Applicant-Attacker to
> self-declare their authorization? The old 3.2.2.4.1 allowed it
> (insecurely), and the proposal below seems to be based on a notion of
> "If the Domain Y holder opts in, then they can authorize the
> Applicant-Attacker A for any future domains, such as Domain Z"
>
> The argument for this goes that, since you know it's Identity I, any
> statement they make about Domain Y should logically be able to extend
> to Domain Z or Domain W, or Public Key X or Public Key F or any other
> sort of dimension, since you're assuming that this Identity I ==
> Applicant-Attacker X, for any/all domains. The old model was that this
> presumption was given by default - 3.2.2.4.1. Under the today's model,
> it's not possible - you have to validate a binding of Domain Y and
> Domain Z and Domain W "separately", as they're requested. Under this
> new model, the argument is being made that the domain holder should be
> able to "opt-in" to skip validation for Domain Z and Domain W, based
> on a WHOIS match, once they've validated Domain Y. I'm sure the
> advocates might not call it "skipping" validation so much as
> "introducing alternative validation", but such alternative validation
> is the semantic equivalent to alternative facts - a problematic
> renaming that hides the fact that you are, in fact, skipping an
> explicit check for Domain Z and Domain W, on the basis of (at the time
> of validation for Z/W) an unrelated Domain Y.
>
> If we expect that the absolute minimum of validations is the
> expectation that "The Domain Holder Y has explicitly authorized
> Applicant to issue any certificate with any public key, for up to 825
> days", then this fails to achieve that minimum goal - because it's not
> an explicit authorization, it's an implicit authorization. Further, as
> discussed previously on the list - in the context of 4.2.1 in
> particular and Ballot 185/186 is general - even that minimum bar is
> problematic, and we can/should do better, such as "The Domain Holder Y
> has explicitly authorized Applicant to issue any certificate with
> Public Key X, for up to 90 days" - to better reflect the fundamental
> assertion that TLS clients rely upon - namely, the binding between the
> Domain Y and Public Key X, based on the authorization of the _current_
> operator/owner of Domain Y.
>
> This is important to note - this is why the BRs require Subscriber
> Agreements to require the Domain Holder Y to notify CAs if they become
> "the previous Domain Holder" (c.f. 9.6.3 (1), 9.6.3 (5), 4.9.1.1 (6),
> 4.9.1.1 (8), 4.9.1.1 (10) ).
>
> This is the crux of why 3.2.2.4.1, in all forms, is problematic -
> because it weakens the less-than-ideal-but-still-the-minimum-today
> level of assurance (explicit authorization) into a notion of implicit
> authorization, on the basis that we trust the Attacker-Applicant A
> more than the Domain Holder Y, on the presumption that Identity I is
> authorized to speak for Domain Y, Z, and W equally.
>
> That is, it's granting retroactive authorization based on
> unknown facts and details when the (previous) authorization
> was granted, so there's no way to be confident that the site
> operator intended for that authorization to be that broadly
> scoped. Every domain should be authorized through contact with
> the domain holder for that domain, and the authorization
> should be scoped only to that domain. We allow you to batch
> authorizations together (such as .2, .3, .4) in some cases,
> but that should not be seen as a forward grant for all future
> authorizations. This was part of the problem with .1.
>
> "there's no way to be confident that the site operator intended
> for that authorization to be that broadly scoped.”
>
> What we have heard from domain registrants is that there are
> domain registrants/contacts who actively do want this level of
> authorization scope. This is very common for large organizations
> which have a central team that manages certificates for the whole
> organization but is distinct from the team that manages domain
> registrations. The organization wants to avoid having the
> registrant team approving each new domain that needs a certificate.
>
> Yes, we have customers that manage a lot of domains and they don’t
> (yet) have the ability to programmatically implement domain
> validation using one of the automated methods for every domain.
> It’s much easier for the Domain owner to be able to make the one
> “global” approval and have all new domains added to their managed
> account without being involved in the approval for everyone.
>
> If were to communicate to the Registrant and they said no, they do
> not permit the global forward approval of all domains (as I
> presume large enterprises like Google and Amazon would do), then
> we would verify each domain as they are supplied for validation.
> For those that do permit approval for all domains, we would be
> sure that the address/value we used to obtain the approval
> (email/phone/sms/postal address) is the same on any future domains.
>
>
> For the reasons above, I think we view this as fundamentally insecure
> and an undesirable property compared to the level of assurance that
> TLS certificates are minimally expected to provide.
>
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/2406a388/attachment-0001.html>
More information about the Validation
mailing list