Re: CAs not compliant with CAA CP/CPS requirement
On Friday, September 8, 2017 at 3:25:20 PM UTC-4, Andrew Ayer wrote: > The BRs state: > > "Effective as of 8 September 2017, section 4.2 of a CA's Certificate > Policy and/or Certification Practice Statement (section 4.1 for CAs > still conforming to RFC 2527) SHALL state the CA's policy or practice > on processing CAA Records for Fully Qualified Domain Names; that policy > shall be consistent with these Requirements. It shall clearly specify > the set of Issuer Domain Names that the CA recognises in CAA 'issue' or > 'issuewild' records as permitting it to issue. The CA SHALL log all > actions taken, if any, consistent with its processing practice." > > Since it is now 8 September 2017, I decided to spot check the CP/CPSes > of some CAs. > > At time of writing, the latest published CP/CPSes of the following CAs > are not compliant with the above provision of the BRs: > > Amazon (https://www.amazontrust.com/repository/) - Does not check CAA > > Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not > specify issuer domain names > > DigiCert (https://www.digicert.com/legal-repository/) - Does not > specify issuer domain names, and processing is not compliant with BRs > ("If a CAA record exists that does not list DigiCert as an authorized > CA, DigiCert verifies that the applicant has authorized issuance, > despite the CAA record.") > > Google Trust Services (https://pki.goog/) - Does not check CAA > > Identrust (https://secure.identrust.com/certificates/policy/ts/) - > Does not check CAA > > Izenpe > (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certificados/es_url/index.shtml) > - Does not specify issuer domain names > > PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA > > Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/) > - Does not specify issuer domain names > > Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) - > No mention of CAA > > Visa (http://www.visa.com/pki/) - Does not check CAA > > > These CAs have compliant CP/CPSes: > > Entrust > > GlobalSign > > GoDaddy > > Let's Encrypt > > QuoVadis > > Trustwave > > > It would be nice to hear confirmation from the non-compliant CAs that they > really are checking CAA as required, and if so, why they overlooked the > requirement to update their CP/CPS. > > Regards, > Andrew Updated IdenTrust TrustID CPS covering CAA record check can be found at https://secure.identrust.com/certificates/policy/ts/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone
Hi all, Thank you for the replies. I am glad that there is agreement these certificates should not have been issued. I am confident that the test behaved correctly, the last edit on the zone file was on Aug 31 17:24, and it reads: crossbear.org. 0 CAA 0 issue ";" So even if requests would somehow have gotten through the iptables rule dropping them, it would definitely not have gotten a permitting record. I also have full pcaps from both name servers serving this domain and can confirm that not a single query response was sent to any server on September 8th and 9th. crossbear.net is a different domain with a different configuration, it is unrelated to this issue. Inigo, I am very happy to debug this in detail offline -- I have plenty of records and data to assist debugging. Kind regards Quirin ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Incident Report - CAA misissuance (was Re: Lack of CAA checking at Comodo)
On 11/09/17 15:30, Rob Stradling via dev-security-policy wrote: Hi Hanno. Thanks for reporting this to us. We acknowledge the problem, and as I mentioned at [1], we took steps to address it this morning. We will follow-up with an incident report ASAP. INCIDENT REPORT We received two Problem Reports - from Hanno Böck on 9th September at 20:10 UTC, and from Jonathan Rudenberg on 10th September at 00:08 UTC - each of which reported that we had misissued a certificate contrary to a published CAA RRset. Jonathan reported this problem at https://bugzilla.mozilla.org/show_bug.cgi?id=1398545, and in https://bugzilla.mozilla.org/show_bug.cgi?id=1398545#c2 Quirin Scheitle provided a further misissuance report. TRIAGING Some Comodo staff saw these reports late on Friday 9th and began to discuss them over the weekend, but they were unable to confirm their accuracy. Indeed, the reports appeared to them to be erroneous, because the logs at their disposal showed that the relevant CAA checks had been performed but the RRsets were empty. Therefore, the only action taken at that point was to escalate the reports to the original developer of our CAA checking code to look at first thing Monday morning. BACKGROUND As you'd expect from the authors of RFC6844, we were an early adopter, deploying our initial CAA checking implementation 2.5 years ago. It executes `dig CAA +dnssec +sigchase +trusted-key=dnssec_trusted.keys` to perform the DNS queries. We chose this approach after concluding that, at that time, it was the least worst option available to us for checking DNSSEC signatures. We deployed a specific version of BIND (9.10.1-P2) because testing had shown that `dig` in the next release of BIND would crash when trying to do DNSSEC validation. WHAT WENT WRONG Our ops team upgraded the servers that our CAA checking code was running on. This included a very-long-awaited transition from a 32-bit to 64-bit OS. Rather than recompile 9.10.1-P2 for 64-bit, our ops engineers upgraded BIND to 9.10.5-P1. Yesterday morning (Monday 11th), when investigating the Problem Reports, the original developer discovered that as a result of that BIND upgrade all of our calls to `dig` were returning the following response: `Invalid option: +sigchase Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt} {global-d-opt} host [@local-server] {local-d-opt} [ host [@local-server] {local-d-opt} [...]] Use "dig -h" (or "dig -h | more") for complete list of options` Unfortunately, this `dig` response was being interpreted by our CAA checking code as a CAA response that contained: no "issue" property, no "issuewild" property, no unrecognized critical properties, etc. This problem had gone undetected due to a combination of reasons: the developer did not ask for BIND to be upgraded and so did not expect any behaviour to have changed; the ops engineers did not realize that upgrading BIND might cause a problem; there wasn't an automated test that would've detected this problem and raised an alarm; CAA RRsets are still fairly uncommon, so nobody noticed that we'd dropped from finding hardly any RRsets to finding zero RRsets; our validation staff only see the results of our CAA processing rather than the complete output from `dig`. ACTION TAKEN TO ADDRESS THE PROBLEM Upon discovery of the failing `dig` calls, we immediately downgraded to BIND 9.10.1-P2 and verified that our CAA checks were then working correctly. We also purged our local cache (of recent `dig` responses) to ensure that the misissuance vector was completely closed. PROBLEM CERTIFICATES The following certificates have all been revoked: Reported by Hanno: https://crt.sh/?id=207082245 Reported by Jonathan: https://crt.sh/?id=207224651 Reported by Quirin: https://crt.sh/?id=208456003 https://crt.sh/?id=208486480 https://crt.sh/?id=208486489 https://crt.sh/?id=208486485 https://crt.sh/?id=208486495 NEW CAA CHECKING IMPLEMENTATION Our initial CAA checking implementation, while functional, was not designed with our current certificate issuance volumes in mind. Consequently, we had been working on a new, much more scalable CAA checking implementation, written in Go. We had expected to deploy this new implementation during Q2 2017, but work on this project was paused due to the uncertainties of CNAME processing that have now been resolved at IETF (see https://www.rfc-editor.org/errata/eid5065) and that will hopefully soon also be resolved at CABForum (see https://cabforum.org/pipermail/public/2017-August/011972.html). DEPLOYING OUR NEW CAA CHECKING IMPLEMENTATION Having fixed our `dig` calls we found that our system was struggling to process the queue of CAA checks quickly enough, and so we accelerated our plans to deploy our new CAA checking implementation. This morning (Tuesday 12th) we verified that our new implementation does a reasonable job when faced with the test cases at https:/
RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone
Hi all, We´ve checked logs and still don´t have a final conclussion but some clues about it. There were 2 attempts to request a cert for crossbear.org, the first one was 10 minutes before and was rejected because of timeout but the second, the one issued, permitted the issuance. # 1st request for crossbear.org at 11:36 11:36:57,399 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (http--0.0.0.0-8443-2) 2017-09-09 11:36:57+08:00;CERT_REQUEST;SUCCESS;CERTIFICATE;CORE;CN=ejbca ws,C=CN;-366638826;;crossbear.org;subjectdn=CN=crossbear.org,C=DE;requestX50 0name=C=DE,O=TUM,CN=crossbear.org;subjectaltname=DNSNAME=crossbear.org;reque staltn ame=;certprofile=2102604971;keyusage=-1;notbefore=;notafter=;sequence=;publi ckey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm9PKsCgR0gsedHsp4UgQLzMc9uf jZvOg5 MkyB8H7DDjuSY3lxcjTMqWHzwMJyJT6q/seCehfXaZ069CQt1vakgvyFhNZT4DhL52FPN3L+EqFI erT9dUH60aL/bssDZ+L1vJ0R1+1vbM/8ZELPl1zrqhaZInMWvp3odxlhT/MXNR1NFZ4GMctWYyxq Xg1N94 eQ1HoG18ssVEZx21La6f+DXldxhUHhJUW6H1v+lSpXA32MMytJ9EfIhl5pGFkIz/hx4T9CNSgxId /qEE2Z5rbl9+vmkjmk5ZqEGOwUlgxxjTVtjp5qJ4TJrtRxu2spKtovvY+b2z4bHT7EjYbBXx00QI DAQAB 11:37:07,416 ERROR [org.jboss.as.ejb3.tx.CMTTxInterceptor] (http--0.0.0.0-8443-2) javax.ejb.EJBTransactionRolledbackException: java.net.SocketTimeoutException more exception stack Caused by: java.lang.IllegalStateException: java.net.SocketTimeoutException at org.ejbca.util.validation.caa.CaaDnsLookup.lookup(CaaDnsLookup.java:534) [caa.jar:] at org.ejbca.util.validation.caa.CaaDnsLookup.lookupDomain(CaaDnsLookup.java:25 7) [caa.jar:] at org.ejbca.util.validation.caa.CaaDnsLookup.performLookupForDomains(CaaDnsLoo kup.java:199) [caa.jar:] at org.ejbca.core.model.validation.CaaValidator.validate(CaaValidator.java:108) [caa.jar:EJBCA 6.9.0.4 Enterprise (r26507)] more exception stack # 2nd request for crossbear.org at 11:44 11:44:06,011 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (http--0.0.0.0-8443-2) 2017-09-09 11:44:06+08:00;CERT_REQUEST;SUCCESS;CERTIFICATE;CORE;CN=ejbca ws,C=CN;-366638826;;crossbear.org;subjectdn=CN=crossbear.org,C=DE;requestX50 0name=C=DE,O=TUM,CN=crossbear.org;subjectaltname=DNSNAME=crossbear.org;reque staltn ame=;certprofile=2102604971;keyusage=-1;notbefore=;notafter=;sequence=;publi ckey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm9PKsCgR0gsedHsp4UgQLzMc9uf jZvOg5 MkyB8H7DDjuSY3lxcjTMqWHzwMJyJT6q/seCehfXaZ069CQt1vakgvyFhNZT4DhL52FPN3L+EqFI erT9dUH60aL/bssDZ+L1vJ0R1+1vbM/8ZELPl1zrqhaZInMWvp3odxlhT/MXNR1NFZ4GMctWYyxq Xg1N94 eQ1HoG18ssVEZx21La6f+DXldxhUHhJUW6H1v+lSpXA32MMytJ9EfIhl5pGFkIz/hx4T9CNSgxId /qEE2Z5rbl9+vmkjmk5ZqEGOwUlgxxjTVtjp5qJ4TJrtRxu2spKtovvY+b2z4bHT7EjYbBXx00QI DAQAB 11:44:06,023 INFO [org.cesecore.keys.validation.KeyValidatorSessionBean] (http--0.0.0.0-8443-2) CAA Validator 'CAAValidator' has permitted issuance of certificates to issuer startcomca.com. We have opened a ticket with Primekey to check with them what could be the issue. Don´t know if between requests there was any change, maybe Quirin can help. We´ve also received another 2 request for crossbear.net which were denied because had a CAA record not listing startcom # 1st request for crossbear.net at 14:40 14:40:12,068 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (http--0.0.0.0-8443-1) 2017-09-09 14:40:12+08:00;CERT_REQUEST;SUCCESS;CERTIFICATE;CORE;CN=ejbca ws,C=CN;-366638826;;crossbear.net;subjectdn=CN=crossbear.net,C=DE;requestX50 0name=C=DE,O=TUM,CN=crossbear.org;subjectaltname=DNSNAME=crossbear.net;reque staltn ame=;certprofile=2102604971;keyusage=-1;notbefore=;notafter=;sequence=;publi ckey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm9PKsCgR0gsedHsp4UgQLzMc9uf jZvOg5 MkyB8H7DDjuSY3lxcjTMqWHzwMJyJT6q/seCehfXaZ069CQt1vakgvyFhNZT4DhL52FPN3L+EqFI erT9dUH60aL/bssDZ+L1vJ0R1+1vbM/8ZELPl1zrqhaZInMWvp3odxlhT/MXNR1NFZ4GMctWYyxq Xg1N94 eQ1HoG18ssVEZx21La6f+DXldxhUHhJUW6H1v+lSpXA32MMytJ9EfIhl5pGFkIz/hx4T9CNSgxId /qEE2Z5rbl9+vmkjmk5ZqEGOwUlgxxjTVtjp5qJ4TJrtRxu2spKtovvY+b2z4bHT7EjYbBXx00QI DAQAB 14:40:12,447 INFO [org.ejbca.util.validation.caa.CaaDnsLookup] (http--0.0.0.0-8443-1) Found CAA Record for domain crossbear.net.: crossbear.net. 300 IN CAA 0 issue ";" 14:40:12,447 INFO [org.ejbca.util.validation.caa.CaaDnsLookup] (http--0.0.0.0-8443-1) Found CAA Record for domain crossbear.net.: crossbear.net. 300 IN CAA 0 iodef "mailto:c...@crossbear.net"; 14:40:12,448 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (http--0.0.0.0-8443-1) 2017-09-09 14:40:12+08:00;VALIDATOR_VALIDATION_FAILED;FAILURE;VALIDATOR; CORE;CN=ejbcaws,C=CN;-366638826;;crossbear.net;msg=CAA Validator 'CAAValidator' failed issuance of certificates to issuer startcomca.com. # 2nd request for crossbear.net at 14:41 14:41:00,891 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (http--0.0.0.0-8443-1) 2017-09-09 14:41:00+08:00;CERT_REQUEST;SUCCESS;CERTIFICATE;CORE;CN=ejbca ws,C=CN;-366638826;;crossbear.net;subjectdn=CN=crossbear.net,C=DE;requestX50 0name=C=DE,O=TUM,CN=cr
Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
Hello, Here is the new version of the draft updated according to the discussion on mozilla-dev-security list. -- Forwarded message -- From: Date: Tue, Sep 12, 2017 at 3:55 PM Subject: New Version Notification for draft-belyavskiy-certificate-l imitation-policy-04.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-certificate-limitation-policy-04.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 04 Title: Certificate Limitation Policy Document date: 2017-09-11 Group: Individual Submission Pages: 7 URL:https://www.ietf.org/internet-drafts/draft-belyavskiy-certif icate-limitation-policy-04.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-certifica te-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate-li mitation-policy-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-cert ificate-limitation-policy-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certific ate-limitation-policy-04 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- SY, Dmitry Belyavsky ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone
Ok, let me investigate this further, maybe I didn´t catch it rightly. For the record, the certificate was revoked Best regards Iñigo Barreira CEO StartCom CA Limited -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of Nick Lamb via dev-security-policy Sent: martes, 12 de septiembre de 2017 12:26 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira wrote: > Futhermore, according to the logs, at the time of checking for a CAA record, there was none. The lookup was succesful and hence allowed the issuance. Given that this contradicts the facts alleged in Quirin's tests and the feedback from BuyPass I would strongly recommend doing further testing to ensure that StartCom's systems detect [and log] timeouts and other failures properly for CAA records. I'm sure Quirin will try to offer reasonable assistance in reproducing the problem. It is definitely worth noting that with DNSSEC _enabled_ a CA ends up having cryptographic proof of their results - which could be recorded in case of any dispute. If you had such proof for the permissive CAA record we wouldn't need to investigate StartCom's systems or policies, we could examine the record and conclude that Querin made an error somewhere and permitted this issuance without knowing anything about StarCom or needing to take you at your word. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA Certificate Problem Report
On 11/09/17 22:28, Jeremy Rowley wrote: > I would support that. I can't recall why it's in there. As the drafter of the section :-), my intent was to make it so that if a site owner were concerned about the possibility that their CAA record or DNS could be spoofed, they could use DNSSEC to solve the problem. I agree that there is an implicit assumption in this requirement, that it is possible to efficiently determine the presence or absence of what we might call "attempted DNSSEC" for a particular domain. (That's not the same thing as "correct, valid, properly-signed, whatever DNSSEC.) If that assumption is not true, we may have to reconsider. I also seem to recall that the intent was not to require that CAs do proper DNSSEC lookups for all CAA requests as long as they were happy to fail closed in the presence of DNSSEC. This again has the above implicit assumption baked into it. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone
On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira wrote: > Futhermore, according to the logs, at the time of checking for a CAA record, > there was none. The lookup was succesful and hence allowed the issuance. Given that this contradicts the facts alleged in Quirin's tests and the feedback from BuyPass I would strongly recommend doing further testing to ensure that StartCom's systems detect [and log] timeouts and other failures properly for CAA records. I'm sure Quirin will try to offer reasonable assistance in reproducing the problem. It is definitely worth noting that with DNSSEC _enabled_ a CA ends up having cryptographic proof of their results - which could be recorded in case of any dispute. If you had such proof for the permissive CAA record we wouldn't need to investigate StartCom's systems or policies, we could examine the record and conclude that Querin made an error somewhere and permitted this issuance without knowing anything about StarCom or needing to take you at your word. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone
Hi Buypass received the problem report at 2017-09-12 00:06 and started investigating early this morning. After investigating what happened we identified an error in our system solution when we have a CAA RR lookup failure. In this case, the DNS CAA RR lookup timed out several times and we mis-interpreted this as permission to issue, without verifying the that the domain was DNSSEC signed. This is not permitted according to BR (see ballot paragraph [1]) and we will fix this as soon as possible. We agree that this certificate should not have been issued and we have revoked the certificate. Regards Mads -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+mads.henriksveen=buypass...@lists.mozilla.org] On Behalf Of Quirin Scheitle via dev-security-policy Sent: tirsdag 12. september 2017 00:24 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone Hi, inspired by the ballot paragraph [1], I set up a domain that is fully DNSSEC signed [2], but does not reply to CAA queries (timeout). I could obtain certificates for this domain from Buypass and Startcom [3]. Other CAs (RapidSSL, GeoTrust, LetsEncrypt) have refused to issue, and GoDaddy and Certum have been stuck in "Pending" for days and will likely not issue. Per my interpretation, and per the discussion in the other CAA/DNSSSEC thread, I believe those should not have been issued. I have reported this to the issuing CAs. What do you think? Kind regards Quirin [1] CAs are permitted to treat a record lookup failure as permission to issue if: the failure is outside the CA’s infrastructure; the lookup has been retried at least once; and the domain’s zone does not have a DNSSEC validation chain to the ICANN root. [2] https://dnssec-debugger.verisignlabs.com/crossbear.org [3] https://crt.sh/?q=crossbear.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone
Hi Quirin, I was going to reply to your email after investigating what happened, but since you´ve posted here, I can share it. I think most of the CAs are strugling with the DNSSEC interpretation or how to solve some of the issues. In our case, I can tell the following: The DNSSEC checking is optional, and at the time of the request we had it disabled so we didn´t check it. According to the logs, this cert was requested at 2017-09-09 11:44 GMT+8 and we enabled it a little bit later 2017-09-09 17:41 GMT+8. As we have had some other issues with the DNSSEC, we have disabled it again and are dealing with Primekey to have a better approach to this issue. Futhermore, according to the logs, at the time of checking for a CAA record, there was none. The lookup was succesful and hence allowed the issuance. Regarding to your question, I think you´re right and this certificate should have not been issued but it´s also true that having the DNSSEC checking optional, this can happen. Best regards Iñigo Barreira CEO StartCom CA Limited -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of Quirin Scheitle via dev-security-policy Sent: martes, 12 de septiembre de 2017 0:24 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone Hi, inspired by the ballot paragraph [1], I set up a domain that is fully DNSSEC signed [2], but does not reply to CAA queries (timeout). I could obtain certificates for this domain from Buypass and Startcom [3]. Other CAs (RapidSSL, GeoTrust, LetsEncrypt) have refused to issue, and GoDaddy and Certum have been stuck in "Pending" for days and will likely not issue. Per my interpretation, and per the discussion in the other CAA/DNSSSEC thread, I believe those should not have been issued. I have reported this to the issuing CAs. What do you think? Kind regards Quirin [1] CAs are permitted to treat a record lookup failure as permission to issue if: the failure is outside the CA’s infrastructure; the lookup has been retried at least once; and the domain’s zone does not have a DNSSEC validation chain to the ICANN root. [2] https://dnssec-debugger.verisignlabs.com/crossbear.org [3] https://crt.sh/?q=crossbear.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
(Mis)-Issuance on CAA Timeout in DNSSEC signed zone
Hi, inspired by the ballot paragraph [1], I set up a domain that is fully DNSSEC signed [2], but does not reply to CAA queries (timeout). I could obtain certificates for this domain from Buypass and Startcom [3]. Other CAs (RapidSSL, GeoTrust, LetsEncrypt) have refused to issue, and GoDaddy and Certum have been stuck in "Pending" for days and will likely not issue. Per my interpretation, and per the discussion in the other CAA/DNSSSEC thread, I believe those should not have been issued. I have reported this to the issuing CAs. What do you think? Kind regards Quirin [1] CAs are permitted to treat a record lookup failure as permission to issue if: the failure is outside the CA’s infrastructure; the lookup has been retried at least once; and the domain’s zone does not have a DNSSEC validation chain to the ICANN root. [2] https://dnssec-debugger.verisignlabs.com/crossbear.org [3] https://crt.sh/?q=crossbear.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy