1398428 - Amazon Trust Services: CAA Misissuances

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

I just submitted the following to [e-mail] and [e-mail]:

The CA "C=US, O=Amazon, OU=Server CA 1B, CN=Amazon", which is operated by DigiCert
and chains to a root owned by Amazon, has issued the following certificates in violation
of the Baseline Requirements' CAA checking requirement:

1. https://crt.sh/?sha256=26F4FFABCF94AA16A85C7F02D9F4604E74A41ACE51DA1C55B732E1618798D04A
2. https://crt.sh/?sha256=2619EAA800BA627CC3C1971DF0BB8006B2831B500935E943799524E81CA3EDAB
3. https://crt.sh/?sha256=D0DA8826B05D5A079E4356D4FED6300A94B0E2B9E6E40FCB6AAEAC1F2163AF2E
4. https://crt.sh/?sha256=300D20D0E63112AD77D09BBA8F02E9B075E265DF21E0FE6F18C38CD11179D43B
5. https://crt.sh/?sha256=CC08B270A8BF66D431E9AC073C7014373F6CE582F1CF5C08CF73C340F91327FB
6. https://crt.sh/?sha256=A3AA9FDC0ED72C29C969E76A929F517EB093A574ED2C248CBAFC785767403FC6

Certificate 1 contains a single DNS identifier for
big.basic.caatestsuite.com.  This DNS name has a CAA resource record
set that is too large to fit within a single DNS UDP packet, but small
enough to fit within a DNS TCP packet.  The only CAA record containing
an issue property is:

big.basic.caatestsuite.com.     IN      CAA     0 issue "caatestsuite.com"

Therefore, only caatestsuite.com is allowed to issue for this identifier.


Certificate 2 contains a single DNS identifier for
cname-deny-sub.basic.caatestsuite.com.  The following DNS records are
relevant:

cname-deny-sub.basic.caatestsuite.com. IN CNAME sub.deny.basic.caatestsuite.com.

deny.basic.caatestsuite.com. IN CAA 0 issue "caatestsuite.com"

There is no CAA record at sub.deny.basic.caatestsuite.com.  According to
RFC 6844, the only CA allowed to issue for cname-deny-sub.basic.caatestsuite.com
is caatestsuite.com.


Certificate 3 contains a single DNS identifier for
refused.caatestsuite-dnssec.com.  Attempts to query the CAA record for
this DNS name result in a REFUSED DNS response.  Since there is a DNSSEC
validation chain from this zone to the ICANN root, CAs are not permitted
to treat the lookup failure as permission to issue.


Certificate 4 contains a single DNS identifier for
missing.caatestsuite-dnssec.com.  This DNS name has no CAA records, but
the zone is missing RRSIG records.  Since there is a DNSSEC validation
chain from this zone to the ICANN root, the DNS lookup should fail and
this failure cannot be treated by the CA as permission to issue.


Certificate 5 contains a single DNS identifier for
expired.caatestsuite-dnssec.com.  This DNS name has no CAA records,
but the zone contains expired RRSIG records.  Since there is a DNSSEC
validation chain from this zone to the ICANN root, the DNS lookup should
fail and this failure cannot be treated by the CA as permission to issue.


Certificate 6 contains a single DNS identifier for
blackhole.caatestsuite-dnssec.com.  All DNS requests for this DNS name
will be dropped, causing a lookup failure.  Since there is a DNSSEC
validation chain from this zone to the ICANN root, CAs are not permitted
to treat the lookup failure as permission to issue.

Comment 1

[Kathleen Wilson]

Peter,

Please update this bug promptly to indicate acknowledgement of the problem and a timeline for resolving the immediate problem.

Then provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 2

[Peter Bowen]

Amazon Trust Services and DigiCert received an email from this reporter yesterday at 22:07 PDT.  ATS replied to the reporter at 02:10 PDT today (approximately four hours later). DigiCert responded to the reporter, copying ATS, at 22:41 PDT and has had ongoing communication since then. As the reporter notes, the issuer in question is operated by DigiCert and cross-signed by Amazon.  

DigiCert posted to m.d.s.p at 02:21 PDT with their initial responses.  In the discussion that has followed, it appears some of the reported problems may not be problems.  ATS is participating in the discussion and will determine what actions, if any, are necessary once it is determined which, if any, of these reports are determined to demonstrate legitimate issues.

Comment 3

[Gervase Markham [:gerv]]

Peter: given Mozilla's stated position on what it expects from CAs for CAA checking at the moment, are any of these issues still considered misissuances?
https://groups.google.com/d/msg/mozilla.dev.security.policy/9y-XTajmOCw/Hjqta1ETAQAJ

Gerv

Comment 4

[Ryan Sleevi]

Peter: Any updates?

Comment 5

[Peter Bowen]

Based on the email above, I believe that DigiCert and ATS are making good faith efforts to do the algorithm in RFC6844, as amended by erratum 5065 and using the "natural" interpretation of DNAMEs.  As discussed in the m.d.s.p forum, the tests above helped drive the discussion on approving erratum 5065 as acceptable and exposed numerous cases where the interaction of the CABF BRs, DNSSEC RFCs and implementations of DNSSEC resulted in unclear and ambiguous requirements that could be interpreted in different ways.


It is my opinion that Mozilla should consider this issue resolved.  We thank Andrew for writing such a comprehensive test suite and actively participating in discussions across multiple forums, both Mozilla hosted and those hosted by other software developers.

Comment 6

[Andrew Ayer]

Certificate 1 is not related to CNAME, DNAME, or DNSSEC.

Comment 7

[Peter Bowen]

Sorry, I didn't mean to imply Certificate 1 was related to CNAME, DNAME, or DNSSEC.  Certificate 1 was specifically discussed on the list and Jeremy indicated on September 11 that they were fixing it (https://groups.google.com/d/msg/mozilla.dev.security.policy/2WxCMEYEbrE/MdgF2NATAgAJ)

Comment 8

[Gervase Markham [:gerv]]

Jeremy: can you confirm the issue leading to certificate 1 is fixed?

Gerv

Comment 9

[Jeremy Rowley]

Yes - it's fixed. We use UDP or TCP as appropriate.