[cabfpub] EXTERNAL: Re: Continuing the discussion on CAA

[Jeremy Rowley]

"CAA records MAY be used by Certificate Evaluators as a possible
   indicator of a security policy violation.  Such use SHOULD take
   account of the possibility that published CAA records changed between
   the time a certificate was issued and the time at which the
   certificate was observed by the Certificate Evaluator."

I know it says this, but I'm not sure how this would ever happen in
practice. That seems more like the role of CT over CAA.



-----Original Message-----
From: Mehner, Carl [mailto:Carl.Mehner at usaa.com] 
Sent: Monday, October 24, 2016 12:24 PM
To: Gervase Markham <gerv at mozilla.org>; Jeremy Rowley
<jeremy.rowley at digicert.com>; CABFPub <public at cabforum.org>
Subject: RE: EXTERNAL: Re: [cabfpub] Continuing the discussion on CAA

> On 24/10/16 16:40, Jeremy Rowley via Public wrote:
> > Has there been an issuance to a third party that CAA would have
> prevented?

We have an internal policy that describes which CAs are allowed for use,
there have been cases where other teams or entities have issued a
certificate that did not fit within our defined policy. Had CAA enforcement
been enabled and the CAs set to hard-fail mode, what we see as a "semantic
mis-issuance" [1] would not have occurred.


> 2) If a customer has a single base domain and needs to issue 6 million 
> certs an hour for the various sub domains, then there isn't a way for 
> the CA to simply accept the base domain's CAA record.
I think that hanging on to responses for a short amount of time would be
good for multiple issuances within time period 'X' like in 

However, as it says in RFC6844:
CAA records MAY be used by Certificate Evaluators as a possible
   indicator of a security policy violation.  Such use SHOULD take
   account of the possibility that published CAA records changed between
   the time a certificate was issued and the time at which the
   certificate was observed by the Certificate Evaluator.

Therefore, when a cached CAA response is 're-checked' and the status has
changed, that must not in and of itself constitute an event worthy of
revocation under 4.9.1.1.12 of the BRs.


[1]
https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-10#section-3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20161024/ebec4a60/attachment-0001.bin>