Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

[Quirin Scheitle]

Hi all,

I have a question regarding processing of CAA records for “wildcard certificates”.

Let’s assume the following CSR:

X509v3 Subject Alternative Name:
DNS: *.example.com
DNS: example.com

Per BR, every SAN DNS name must be checked separately.
Now, my interpretation would be that for *.example.com, you would query example.com for an “issuewild" entry,
and for example.com, you would query example.com for an "issue" entry.

What if the zone file looks like this:
example.com 0 CAA 0 issue “;”
example.com 0 CAA 0 issuewild “yourca”

My interpretation would be that “yourca” (as any other CA) would not be permitted to issue this certificate,
as it is not allowed to issue for the non-wildcard part example.com.

A plunge through the related documents [see appendix] seems to point in that direction, but I still have doubts.

What is the community interpretation?

Kind regards
Quirin

---------

Appendix:

BR defines a wildcard certificate as "Wildcard Certificate: A Certificate containing an asterisk (*) in the left‐most position of any of the Subject Fully‐Qualified Domain Names contained in the Certificate.” —> This means that the whole certificate is a wildcard certificate.

—

RFC2818:

> Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

—> example.com is not part of *.example.com

RFC6844:

> " issuewild <Issuer Domain Name> [; <name>=<value> ]* : The issuewild
> property entry authorizes […] to issue wildcard certificates for the
> domain in which the property is published."


> "Given a request for a specific domain X, or a request for a wildcard
> domain *.X, the relevant record set R(X) is determined as follows:”

—> The 'relevant record set' is specified per domain

> "issuewild properties MUST be ignored when processing a request for a
> domain that is not a wildcard domain."

—> Especially this last paragraph seems to indicate that the CSR above would not be permitted to be issued. Also, it specifically uses “domain” and not “certificate”.

[cbon...@trustwave.com]

Hi Quirin,
You are correct that the certificate will not issue. Here's a breakdown of the steps taken by the "yourca" CA to check CAA:

1) Retrieval of CAA records at "example.com" for SAN "*.example.com".
2) Both an "issue" and "issuewild" record exist, and the SAN "*.example.com" is a wildcard SAN, so the "issuewild" record has precedence over the "issue" record (RFC 6844, section 5.3 states: "issuewild properties take precedence over issue properties when specified").
3) The identifying domain name in the "issuewild" record is compared with the set of yourca's identifying domain names. A matching identifying domain name is found, so the "yourca" CA is permitted to issue for "*.example.com".
4) Retrieval of CAA records at "example.com" for SAN "example.com".
5) As stated in step 2, both "issue" and "issuewild" records exist, but the SAN "example.com" is not a wildcard SAN, so the "issuewild" record is ignored (RFC 6844, section 5.3 states: "issuewild properties MUST be ignored when processing a request for a domain that is not a wildcard domain").
5) The identifying domain name in the "issue" record is the empty string, so "yourca" can't issue for "example.com".
6) The issuance attempt fails.

Hope that helps.

Thanks,
Corey Bonnell

[Jeremy Rowley]

IMO - This is the correct interpretation. Yourca could disuse the wildcard cert for *.example.com but could not issue a cert with multiple SANs containing both *.example.com and example.com.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/MNXxMtzz89XRxiRyFyxBbvTwQQcHgZB9IFwfnL9V-lk=?d=c7fMA0piGIiHHXF4k6ez3WytUPYbXG2mFTDF9D-JpVQvtrFTk3sYWf4GgAMkkmVSay02KMsTdsjWHEXtAA8rVZ0_63qhP6cZXUw2gvGLxiPXjmOcL7MKJrPN1j1guN72GYX71nqJLhvb8z34LvE7wDNVWd1rGbbfscOgbXJyN3WTgv1Ujl8M2_GqMITGgOBcmxxH4FWWfymS7fvTViZsF03yWEsQMoz3e6Nam1msFxNI0ukgXXn8FwQeOTBvKmxpqWYZAXt9bt2S4pNsAKY1ieOZt8ddwXRqG01A28s3HdP-ZPbT8JHfd1CFL6N9qq4FgplLiGsuBFhpixIGwc7rHrUg7Ru0S2vMjvz2YDLEKSQQqY1cAp8FEVtsVbfMgcHWtda-j4VTa4eiaDSKeW1dtTK21TGe5tdpanpA9tG8ivvihjYybEGxQsI0_WZsK69a2j_HjWEZS73A8QZziaMtmDgV7fmATjvjkZz8Brl5glqtaWBDwAXm9hxC-KQ%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Quirin Scheitle]

Dear Corey,
Dear Jeremy,

thank you for your responses! I had seen a certificate with this pattern, and confirmed by your answers have done a more complete scan.

I found 5 certificates with that pattern that had CAA records set at issuance time (approximated by “not valid before” and SCT) that would not have allowed issuance per our discussion.

I am aware that CAA records are only for consumption by CAs, and that my 3rd-party lookups do not prove anything — CAs may either have received different replies, or the records may have undergone a brief global change so my 24-hour-interval does not capture the change.

Yet the historic consistency of DNS data for these domains, coupled with a certain ambiguity around this case, may provide anecdotal evidence to look into these 5 issuances?

Details below:
(Please note that the DNS replies are generally stable for more days than displayed).

======== Certificate 1 ========
https://crt.sh/?id=215028491
X509v3 Subject Alternative Name:
DNS:*.netservicesgroup.com
DNS:netservicesgroup.com
Issuer COMODO CA Limited
DNS history (Certificate issued on Sep 20):
2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issue ";"
2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issue ";"
2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issue “;"
2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issue ";"
2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issuewild “comodoca.com"
2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issue “;"

======== Certificate 2 =======
https://crt.sh/?id=211113116
X509v3 Subject Alternative Name:
DNS:*.trnava-vuc.sk
DNS:trnava-vuc.sk
Issuer: thawte, Inc.
DNS history (Certificate issued on Sep 13)
2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issuewild "symantec.com"
2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issuewild "thawte.com"
2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issue ";"
2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issue ";"

======== Certificate 3 ========
https://crt.sh/?id=226175601
X509v3 Subject Alternative Name:
DNS:*.drillisch-online.de
DNS:drillisch-online.de
Issuer: COMODO CA Limited
DNS history (Certificate issued on Sep 29):
2017-09-28:drillisch-online.de. 3600 IN CAA 0 issuewild "globalsign.com"
2017-09-28:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
2017-09-28:drillisch-online.de. 3600 IN CAA 0 issue ";"
2017-09-29:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
2017-09-29:drillisch-online.de. 3600 IN CAA 0 issue ";"
2017-09-30:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
2017-09-30:drillisch-online.de. 3600 IN CAA 0 issue ";"

======= Certificate 4 =======
https://crt.sh/?id=221763552
X509v3 Subject Alternative Name:
DNS:*.uhlhosting.ch
DNS:uhlhosting.ch
Issuer: Comodo
DNS history (Certificate issued on Sep 29):
2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com"
2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issue “;”
2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com”
2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issue “;”
2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com”
2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issue “;”
2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com"
2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issue “;”

======== Certificate 5 ========
https://crt.sh/?id=211729608
X509v3 Subject Alternative Name:
DNS:*.provida.net
DNS:provida.net
Issuer: COMODO CA Limited
DNS history (Certificate issued on Sep 15):
2017-09-13:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-13:provida.net. 600 IN CAA 0 issuewild "symantec.com"
2017-09-13:provida.net. 600 IN CAA 0 issue ";"
2017-09-14:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-14:provida.net. 600 IN CAA 0 issuewild “symantec.com"
2017-09-14:provida.net. 600 IN CAA 0 issue “;"
2017-09-15:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-15:provida.net. 600 IN CAA 0 issuewild "symantec.com"
2017-09-15:provida.net. 600 IN CAA 0 issue ";"
2017-09-16:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-16:provida.net. 600 IN CAA 0 issuewild “symantec.com"
2017-09-16:provida.net. 600 IN CAA 0 issue “;"
2017-09-17:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-17:provida.net. 600 IN CAA 0 issuewild "symantec.com"
2017-09-17:provida.net. 600 IN CAA 0 issue ";"


Kind regards
Quirin

> On 16. Nov 2017, at 04:37, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> IMO - This is the correct interpretation. Yourca could disuse the wildcard cert for *.example.com but could not issue a cert with multiple SANs containing both *.example.com and example.com.

> On 15. Nov 2017, at 16:37, cbonnell--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Wednesday, November 15, 2017 at 8:11:18 AM UTC-5, Quirin Scheitle wrote:

> Hi Quirin,
> You are correct that the certificate will not issue. Here's a breakdown of the steps taken by the "yourca" CA to check CAA:
>
> 1) Retrieval of CAA records at "example.com" for SAN "*.example.com".
> 2) Both an "issue" and "issuewild" record exist, and the SAN "*.example.com" is a wildcard SAN, so the "issuewild" record has precedence over the "issue" record (RFC 6844, section 5.3 states: "issuewild properties take precedence over issue properties when specified").
> 3) The identifying domain name in the "issuewild" record is compared with the set of yourca's identifying domain names. A matching identifying domain name is found, so the "yourca" CA is permitted to issue for "*.example.com".
> 4) Retrieval of CAA records at "example.com" for SAN "example.com".
> 5) As stated in step 2, both "issue" and "issuewild" records exist, but the SAN "example.com" is not a wildcard SAN, so the "issuewild" record is ignored (RFC 6844, section 5.3 states: "issuewild properties MUST be ignored when processing a request for a domain that is not a wildcard domain").
> 5) The identifying domain name in the "issue" record is the empty string, so "yourca" can't issue for "example.com".
> 6) The issuance attempt fails.
>
> Hope that helps.
>
> Thanks,
> Corey Bonnell

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Rob Stradling]

Hi Quirin.

I agree that Comodo should not have issued certificates 1, 3, 4 and 5.

When issuing a "single domain" certificate to (for example)
www.example.com or *.example.com, it's fairly common practice for CAs to
also include in the certificate a SAN.dNSName for the "base domain"
(e.g., example.com). (Similarly, if the certificate request is for
example.com, some CAs will add a SAN.dNSName for www.example.com).

Due to a bug in our CAA checking implementation, we were failing to
perform CAA checks for these extra dNSNames that weren't explicitly
requested by customers. I believe that this is why we did not block
issuance of the 4 certificates you identified.

We spotted this bug a few weeks ago (sorry, I don't have a note of
precisely when), during internal testing against Andrew Ayer's excellent
CAA test suite [1]. We prepared a fix.

As promised in our earlier CAA incident report [2], we engaged "the
services of an external security consultant to independently assess our
new CAA checking implementation and to work with us to ensure that it
behaves correctly". The consultant also identified this bug.

The fix was deployed to our production systems on Friday 17th November.


[1] https://caatestsuite.com/
See the "Special Tests" section.

[2]
https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg08054.html

On 17/11/17 14:41, Quirin Scheitle via dev-security-policy wrote:
> Dear Corey,
> Dear Jeremy,
>
> thank you for your responses! I had seen a certificate with this pattern, and confirmed by your answers have done a more complete scan.
>
> I found 5 certificates with that pattern that had CAA records set at issuance time (approximated by “not valid before” and SCT) that would not have allowed issuance per our discussion.
>
> I am aware that CAA records are only for consumption by CAs, and that my 3rd-party lookups do not prove anything — CAs may either have received different replies, or the records may have undergone a brief global change so my 24-hour-interval does not capture the change.
>
> Yet the historic consistency of DNS data for these domains, coupled with a certain ambiguity around this case, may provide anecdotal evidence to look into these 5 issuances?
>
> Details below:
> (Please note that the DNS replies are generally stable for more days than displayed).
>
> ======== Certificate 1 ========
> https://crt.sh/?id=215028491

> X509v3 Subject Alternative Name:

> DNS:*.netservicesgroup.com
> DNS:netservicesgroup.com
> Issuer COMODO CA Limited
> DNS history (Certificate issued on Sep 20):
> 2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
> 2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issue ";"
> 2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
> 2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issue ";"
> 2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
> 2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issue “;"
> 2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
> 2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issue ";"
> 2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issuewild “comodoca.com"
> 2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issue “;"
>
> ======== Certificate 2 =======
> https://crt.sh/?id=211113116

> X509v3 Subject Alternative Name:

> DNS:*.trnava-vuc.sk
> DNS:trnava-vuc.sk
> Issuer: thawte, Inc.
> DNS history (Certificate issued on Sep 13)
> 2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issuewild "symantec.com"
> 2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
> 2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
> 2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
> 2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
> 2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
> 2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issuewild "thawte.com"
> 2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issue ";"
> 2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
> 2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
> 2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
> 2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
> 2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
> 2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
>
> ======== Certificate 3 ========
> https://crt.sh/?id=226175601

> X509v3 Subject Alternative Name:

> DNS:*.drillisch-online.de
> DNS:drillisch-online.de
> Issuer: COMODO CA Limited
> DNS history (Certificate issued on Sep 29):
> 2017-09-28:drillisch-online.de. 3600 IN CAA 0 issuewild "globalsign.com"
> 2017-09-28:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
> 2017-09-28:drillisch-online.de. 3600 IN CAA 0 issue ";"
> 2017-09-29:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
> 2017-09-29:drillisch-online.de. 3600 IN CAA 0 issue ";"
> 2017-09-30:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
> 2017-09-30:drillisch-online.de. 3600 IN CAA 0 issue ";"
>
> ======= Certificate 4 =======
> https://crt.sh/?id=221763552

> X509v3 Subject Alternative Name:

> DNS:*.uhlhosting.ch
> DNS:uhlhosting.ch
> Issuer: Comodo
> DNS history (Certificate issued on Sep 29):
> 2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com"
> 2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issue “;”
> 2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com”
> 2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issue “;”
> 2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com”
> 2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issue “;”
> 2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com"
> 2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issue “;”
>
> ======== Certificate 5 ========
> https://crt.sh/?id=211729608

> X509v3 Subject Alternative Name:

>> Hi Quirin,
>> You are correct that the certificate will not issue. Here's a breakdown of the steps taken by the "yourca" CA to check CAA:
>>
>> 1) Retrieval of CAA records at "example.com" for SAN "*.example.com".
>> 2) Both an "issue" and "issuewild" record exist, and the SAN "*.example.com" is a wildcard SAN, so the "issuewild" record has precedence over the "issue" record (RFC 6844, section 5.3 states: "issuewild properties take precedence over issue properties when specified").
>> 3) The identifying domain name in the "issuewild" record is compared with the set of yourca's identifying domain names. A matching identifying domain name is found, so the "yourca" CA is permitted to issue for "*.example.com".
>> 4) Retrieval of CAA records at "example.com" for SAN "example.com".
>> 5) As stated in step 2, both "issue" and "issuewild" records exist, but the SAN "example.com" is not a wildcard SAN, so the "issuewild" record is ignored (RFC 6844, section 5.3 states: "issuewild properties MUST be ignored when processing a request for a domain that is not a wildcard domain").
>> 5) The identifying domain name in the "issue" record is the empty string, so "yourca" can't issue for "example.com".
>> 6) The issuance attempt fails.
>>
>> Hope that helps.
>>
>> Thanks,
>> Corey Bonnell
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Gervase Markham]

On 24/11/17 11:37, Rob Stradling wrote:
> When issuing a "single domain" certificate to (for example)
> www.example.com or *.example.com, it's fairly common practice for CAs to
> also include in the certificate a SAN.dNSName for the "base domain"
> (e.g., example.com).  (Similarly, if the certificate request is for
> example.com, some CAs will add a SAN.dNSName for www.example.com).

IMO these two processes are not at all "similar".

Validate example.com -> add "www.example.com": seems fine to me, and a
reasonable accommodation to a common customer desire.

Validate www.example.com -> add "example.com": not at all fine.

Validate *.example.com -> add "example.com": still dodgy IMO.

I seem to remember we have come across this before, and I thought we
said it was not to be done. But perhaps that didn't make it into our
policy. Do we need to add it?

Gerv

[Gervase Markham]

On 24/11/17 11:37, Rob Stradling wrote:

> When issuing a "single domain" certificate to (for example)
> www.example.com or *.example.com, it's fairly common practice for CAs to
> also include in the certificate a SAN.dNSName for the "base domain"
> (e.g., example.com).  (Similarly, if the certificate request is for
> example.com, some CAs will add a SAN.dNSName for www.example.com).

[Rob Stradling]

On 24/11/17 12:25, Gervase Markham via dev-security-policy wrote:
> On 24/11/17 11:37, Rob Stradling wrote:

>> When issuing a "single domain" certificate to (for example)
>> www.example.com or *.example.com, it's fairly common practice for CAs to
>> also include in the certificate a SAN.dNSName for the "base domain"
>> (e.g., example.com).  (Similarly, if the certificate request is for
>> example.com, some CAs will add a SAN.dNSName for www.example.com).
>

> IMO these two processes are not at all "similar".

The similarity I was talking about is that, in both cases, the CA
includes a dNSName in the cert that the subscriber did not explicitly
request.

> Validate example.com -> add "www.example.com": seems fine to me, and a
> reasonable accommodation to a common customer desire.
>
> Validate www.example.com -> add "example.com": not at all fine.
>
> Validate *.example.com -> add "example.com": still dodgy IMO.

I agree. However, my previous message in this thread concerned a
deficiency (since fixed) in Comodo's CAA checks, not Comodo's domain
validation checks.

> I seem to remember we have come across this before, and I thought we
> said it was not to be done. But perhaps that didn't make it into our
> policy.

Yes, this has come up before. It was formerly Comodo's practice to...
"consider proof of control of 'www.<base_domain>' as also proving
control of '<base_domain>' (except where '<base_domain>' is a public
suffix)" [1]

> Do we need to add it?

Now that only the "Ten Blessed Methods" of domain validation are
permitted, I think it's clear that it's "not to be done". (But feel
free to "add it" if you think it would be useful).


[1]
https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg04274.html

[Jakob Bohm]

I seem to recall this was discussed in relation to WoSign or the Korean
RA for Symantec. But the discussion was about improperly using the
"validation via agreed upon website change to www.example.com implies
valid control of example.com" as "validation via agreed upon website
change to userchosensubdomain.example.com implies valid control of
example.com", thus allowing misissuance for delegated subdomains of
project hosts, universities etc.

This rule is normally limited to BR method 3.2.2.4.6 and similar, based
upon considering the specific subdomain www as having similar domain
authority as the well-known e-mail address "hostmaster@" .

However extending that logic (if acceptable for the web-site change
method) to other checks (such as CAA or whois lookup) is obviously
wrong, though one can easily imagine accidentally inserting the CAA
checking code at the wrong point in a validation procedure thus
forgetting to run it for the implied bonus SANs resulting from domain
ownership validation.

An equally probable mistake that should thus be included in test suites
is validating control of "example.com" via a strong method (such as
whois checks + EV checks + DNS change), then issuing for example.com,
www.example.com and mail.example.com without checking if there is a
contradictory CAA for one of those names. Noting that in this case
there is no requirement for those subdomains to even exist at the time
of issuance.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Nick Lamb]

On Fri, 24 Nov 2017 12:25:40 +0000
Gervase Markham via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> Validate example.com -> add "www.example.com": seems fine to me, and a
> reasonable accommodation to a common customer desire.
>
> Validate www.example.com -> add "example.com": not at all fine.
>
> Validate *.example.com -> add "example.com": still dodgy IMO.

All of these can be a problem, and I would like us to have as the end
goal forbidding all these practices, but I recognise that it's
unrealistic to achieve that in the short term.

The thing is, extraneous names on a certificate present a subtle
security flaw, even if control over those names was validated properly

Extraneous names can appear in a CSR as a result of the applicant
making a bad security choice. But that's not our domain here, bad
choices by Relying Parties or Applicants are their problem. Bad choices
by the CAs can harm everybody and we should be trying to move things in
the right direction on that front.

Anyway, let me illustrate the risk:

Suppose I have two HTTPS servers named charlie and dave, charlie
provides web pages on https://www.example.com/,
https://example.com/, and also a not-for-humans API service
https://example.com:8443/

Meanwhile dave provides https://forum.example.com/,
https://blog.example.com/ and https://demo.example.com. It defaults to
forum because we have some Internet Explorer users who expect that to
work.

As the IT manager I obtain two certificates, one for charlie and one
for dave. I am slightly surprised that the one for dave, for which I
requested *.example.com, ends up being *.example.com and example.com
because of my chosen CA's "free upgrade". But I see no immediate
problem with this and wave it through. For charlie I just have a
certificate naming www.example.com and example.com as expected.

Now, a Bad Guy discovers a bug in the crappy PHP forum software I am
using which lets them read items from the error logs of the forum
software by mangling parameters to an image request, if for example an
erroneous HTTP POST is made they get to see all the details this way...

But the Bad Guy is smart, they don't use this bug to annoy forum
dwellers. Instead they sign up for a forum account, if necessary buying
a cheap product from me with a throw-away card so that they can join.

Then they MITM one or more valuable customers. When the customer uses a
POST API at https://example.com:8443/ the Bad Guy can't interpose their
own service because of the Web PKI (hooray) but they can redirect the
packets to dave which will present a certificate
valid for https://example.com:8443/ even though that's not what I
needed or asked for, and unable to recognise requests for example.com
it will default to the forum software...

The forum software doesn't understand the API calls, it will log
everything it sees as an error, and the Bad Guy can read that using the
forum software bug.

As I said, we can't stop Subscribers from choosing to expose themselves
to this risk without making the Web PKI annoying to the point of being
unusable. But CAs can and should try to encourage subscribers to put
less names on a certificate, not more, including by gradually
eliminating policies that add extra names "free".


Part of the way forward is for software vendors to help their Customers
to ask for the right certificate. It's crazy that many popular web
servers won't even help you cook up a CSR for the names actually being
served by that server for example, so that unless they're pretty savvy
we're left guessing which names the customer really "needs".

[Tom]

> The thing is, extraneous names on a certificate present a subtle
> security flaw, even if control over those names was validated properly
>

I agree, if the user is not fully aware of these addition, it can add
subtle security flaw such as "virtual host confusion attacks" (
http://antoine.delignat-lavaud.fr/doc/www15.pdf ) or bugs with http2
connection coalescing (
https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ )

[Jakob Bohm]

On 27/11/2017 19:37, Nick Lamb wrote:
> On Fri, 24 Nov 2017 12:25:40 +0000
> Gervase Markham via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> Validate example.com -> add "www.example.com": seems fine to me, and a
>> reasonable accommodation to a common customer desire.
>>
>> Validate www.example.com -> add "example.com": not at all fine.
>>
>> Validate *.example.com -> add "example.com": still dodgy IMO.
>
>
> All of these can be a problem, and I would like us to have as the end
> goal forbidding all these practices, but I recognise that it's
> unrealistic to achieve that in the short term.
>
> The thing is, extraneous names on a certificate present a subtle
> security flaw, even if control over those names was validated properly
>
> Extraneous names can appear in a CSR as a result of the applicant
> making a bad security choice. But that's not our domain here, bad
> choices by Relying Parties or Applicants are their problem. Bad choices
> by the CAs can harm everybody and we should be trying to move things in
> the right direction on that front.
>

The inclusion of example.com with *.example.com is a long standing
standard practice based on the fact that most subscribers don't realize
that *.example.com doesn't already cover example.com. The validations
needed for *.example.com are a full superset of those needed for
example.com, with the sole exception that the formal wording of the CAA
specification allows a domain to set up CAA records that allow
*.example.com but prohibit example.com. One could reasonably discuss if
this is a bug in the CAA specification, but until then, CAs are formally
required to check for the scenario and reject the application.

The inclusion of example.com with www.example.com is a tradition, but it
would be good if CAs allowed applicants to deselect it in the rare cases
where they don't intend to use it.

While your scenario below sounds compelling, it is very much a contrived
scenario of the type usually used to trick organizations into making bad
policy decisions.

Due to the cost of publicly trusted certificates, many organizations
could, in the same scenario, obtain just the *.example.com + example.com
certificate and install it on both servers.

[Jakob Bohm]

On 28/11/2017 02:29, Jakob Bohm wrote:
> On 27/11/2017 19:37, Nick Lamb wrote:
>> On Fri, 24 Nov 2017 12:25:40 +0000
>> Gervase Markham via dev-security-policy
>> <dev-secur...@lists.mozilla.org> wrote:
>>

> ...

> While your scenario below sounds compelling, it is very much a contrived
> scenario of the type usually used to trick organizations into making bad
> policy decisions.
>
> Due to the cost of publicly trusted certificates, many organizations
> could, in the same scenario, obtain just the *.example.com + example.com
> certificate and install it on both servers.
>

*would, not could

[Ryan Sleevi]

On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 27/11/2017 19:37, Nick Lamb wrote:
>

>> On Fri, 24 Nov 2017 12:25:40 +0000
>> Gervase Markham via dev-security-policy
>> <dev-secur...@lists.mozilla.org> wrote:
>>
>> Validate example.com -> add "www.example.com": seems fine to me, and a
>>> reasonable accommodation to a common customer desire.
>>>
>>> Validate www.example.com -> add "example.com": not at all fine.
>>>
>>> Validate *.example.com -> add "example.com": still dodgy IMO.
>>>
>>
>>
>> All of these can be a problem, and I would like us to have as the end
>> goal forbidding all these practices, but I recognise that it's
>> unrealistic to achieve that in the short term.
>>
>> The thing is, extraneous names on a certificate present a subtle
>> security flaw, even if control over those names was validated properly
>>
>> Extraneous names can appear in a CSR as a result of the applicant
>> making a bad security choice. But that's not our domain here, bad
>> choices by Relying Parties or Applicants are their problem. Bad choices
>> by the CAs can harm everybody and we should be trying to move things in
>> the right direction on that front.
>>
>>

> The inclusion of example.com with *.example.com is a long standing
> standard practice based on the fact that most subscribers don't realize
> that *.example.com doesn't already cover example.com. The validations
> needed for *.example.com are a full superset of those needed for
> example.com, with the sole exception that the formal wording of the CAA
> specification allows a domain to set up CAA records that allow
> *.example.com but prohibit example.com. One could reasonably discuss if
> this is a bug in the CAA specification, but until then, CAs are formally
> required to check for the scenario and reject the application.
>
> The inclusion of example.com with www.example.com is a tradition, but it
> would be good if CAs allowed applicants to deselect it in the rare cases
> where they don't intend to use it.
>

> While your scenario below sounds compelling, it is very much a contrived
> scenario of the type usually used to trick organizations into making bad
> policy decisions.
>
> Due to the cost of publicly trusted certificates, many organizations
> could, in the same scenario, obtain just the *.example.com + example.com
> certificate and install it on both servers.

Hi Jakob,

Please note the discussion is not about whether it's problematic to include
both, but how you validate. I don't believe anyone has suggested it's not
OK to include both, merely to ensure that the validation performed is
appropriate for both.

It's absolutely intentional that CAA can allow *.example.com and disallow
example.com. This is not something "One could reasonably discuss if this is
a bug", because it's an explicit intentional design choice documented
within the RFC. This isn't even subtle - it's called out. It's not about
being a 'contrived scenario' either - it's about ensuring the appropriate
level of validation.

As to your remarks about cost, I think that's about an argument about a
decade out of date, nor particularly germane to the level of security we
should expect from the CA ecosystem.

[Jakob Bohm]

Nick Lamb, in the message I replied to, clearly suggested as much, and
provided a contrived scenario to "prove" that point.

> It's absolutely intentional that CAA can allow *.example.com and disallow
> example.com. This is not something "One could reasonably discuss if this is
> a bug", because it's an explicit intentional design choice documented
> within the RFC. This isn't even subtle - it's called out. It's not about
> being a 'contrived scenario' either - it's about ensuring the appropriate
> level of validation.
>

I was not aware this was an intentional complication by the RFC authors.

I still believe most (not all) occurrences of this CAA record
configuration will be either user error or dedicated CA compliance
tests.

> As to your remarks about cost, I think that's about an argument about a
> decade out of date, nor particularly germane to the level of security we
> should expect from the CA ecosystem.
>

I am referring to the cost to the certificate subscriber, specifically
the cost of paying for two properly validated certificates rather than
two. Nick Lamb's scenario involved someone deliberately ordering both
*.example.com and www.example.com as separate certificates, along with
other circumstances.

[Nick Lamb]

On Tue, 28 Nov 2017 04:26:30 +0100

Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> Nick Lamb, in the message I replied to, clearly suggested as much, and
> provided a contrived scenario to "prove" that point.

That's true, and I apologise if the effect was to de-rail the thread,
but I certainly don't concede that just because the scenario was
contrived it won't happen.

I think like spear phishing we can expect to see sophisticated
criminals targeting organisations through this sort of vulnerability,
so-to-say "casing the joint" before their attack, figuring out exactly
which services exist, what infrastructure is shared or public, looking
for weaknesses. A CA needn't make that job easier.

> I am referring to the cost to the certificate subscriber, specifically
> the cost of paying for two properly validated certificates rather than
> two. Nick Lamb's scenario involved someone deliberately ordering both
> *.example.com and www.example.com as separate certificates, along with
> other circumstances.

The price paid by the subscriber to a traditional commercial CA has
essentially nothing to do with the marginal cost of issuing more
certificates. If it did Let's Encrypt would have bankrupted its sponsor
companies months ago.

Nick.

[Jakob Bohm]

On 28/11/2017 15:53, Nick Lamb wrote:
> On Tue, 28 Nov 2017 04:26:30 +0100
> Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> Nick Lamb, in the message I replied to, clearly suggested as much, and
>> provided a contrived scenario to "prove" that point.
>
> That's true, and I apologise if the effect was to de-rail the thread,
> but I certainly don't concede that just because the scenario was
> contrived it won't happen.
>
> I think like spear phishing we can expect to see sophisticated
> criminals targeting organisations through this sort of vulnerability,
> so-to-say "casing the joint" before their attack, figuring out exactly
> which services exist, what infrastructure is shared or public, looking
> for weaknesses. A CA needn't make that job easier.
>

Your scenario required a number of specific actions and vulnerabilities
at the victim end of things, most notably ordering a wildcard
certificate and (unusually) not wanting it to cover the case of no label
at the wildcard point, but also relying on the absence (after seeing its
presence) of that SAN in setting up the handling of URLs for that
service on the second server, and that server being vulnerable.

One could certainly argue that a CA should allow the subscriber to
explicitly deselect the default bonus SANs if a subscriber really wants
a certificate without that SAN. But including certain traditional
related SAN values at no extra charge and by default is generally a good
thing.

>> I am referring to the cost to the certificate subscriber, specifically
>> the cost of paying for two properly validated certificates rather than
>> two. Nick Lamb's scenario involved someone deliberately ordering both
>> *.example.com and www.example.com as separate certificates, along with
>> other circumstances.
>
> The price paid by the subscriber to a traditional commercial CA has
> essentially nothing to do with the marginal cost of issuing more
> certificates. If it did Let's Encrypt would have bankrupted its sponsor
> companies months ago.
>

The price paid by the subscriber to a commercial CA /is/ the marginal
cost as far as the subscriber is concerned. Thus it motivates
subscribers to purchase fewer certificates if possible. And that's what
I was referring to, not the cost to the CA or how that cost might
motivate the CA.