Re: CAs not compliant with CAA CP/CPS requirement

2017-09-12 Thread identrust--- via dev-security-policy 
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

2017-09-12 Thread Quirin Scheitle via dev-security-policy 
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)

2017-09-12 Thread Rob Stradling via dev-security-policy 

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

RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

2017-09-12 Thread Inigo Barreira via dev-security-policy 
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

RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

2017-09-12 Thread Inigo Barreira via dev-security-policy 
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

2017-09-12 Thread Gervase Markham via dev-security-policy 
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

2017-09-12 Thread Nick Lamb via dev-security-policy 
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

2017-09-12 Thread Mads Egil Henriksveen via dev-security-policy 
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

2017-09-12 Thread Inigo Barreira via dev-security-policy 
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

2017-09-12 Thread Quirin Scheitle via dev-security-policy 
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

Re: CAA Certificate Problem Report

2017-09-12 Thread Adriano Santoni via dev-security-policy 

+1


Il 11/09/2017 23:28, Jeremy Rowley via dev-security-policy ha scritto:

I would support that.  I can't recall why it's in there.

-Original Message-
From: Jonathan Rudenberg [mailto:jonat...@titanous.com]
Sent: Monday, September 11, 2017 3:19 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report



On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
 wrote:

For a little more context, the idea is that we can speed up the CAA check for 
all customers while working with those who have DNSSEC to make sure they aren't 
killing performance.  If there's a way to group them easily into buckets 
(timeout + quick does DNSSEC exist check), working on improving the experience 
for that particular set of customers is easier. That bucket can then be 
improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple 
CAs and the fact that it’s optional in the CAA RFC, what do you think about 
proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

Jonathan


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy




smime.p7s
Description: Firma crittografica S/MIME
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy