[cabfpub] Draft CAA motion (3)

Jeremy Rowley jeremy.rowley at digicert.com
Fri Jan 13 21:05:29 UTC 2017

And it seems like Entrust gave precise data. They’d like a year to implement. I don’t see how this isn’t specific. 


From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Thursday, January 12, 2017 3:50 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Draft CAA motion (3)


I would prefer if we base our time decisions on actual data, not hypothetical data.


Put differently: Is 6 months sufficient for DigiCert to implement? Is it sufficient for Entrust?


Those are things we can speak to. But unfortunately, as both the CA/B Forum and as browser vendors, we can't just go talk to "a lot of CAs" because it's unclear who the "lot of CAs" you're thinking of is. We could send a note to every CA, sure, but isn't the point of the Forum specifically to facilitate and ease the communication that had historically been accomplished by sending mails to every CA? And to ensure they had the opportunity to offer feedback?


Concrete examples allow for meaningful data gathering and discussion, which is good, and by no means unreasonable if there are specific needs. But general examples of "Well, what about a CA that didn't do X" are not only unhelpful but they're actively harmful to making improvements, and so such arguments should absolutely be ignored.


On Thu, Jan 12, 2017 at 12:50 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

I don’t think the implementation request is too generic. Specifically, we know a lot of CAs utilize out of the box software rather than something home-grown. Based on the amount of time it took these providers to implement OCSP, the exact same issue will likely arise when implementing CAA. Others can comment, but I doubt CAA support is on the radar of most of the CA software developers.


From: Public [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> ] On Behalf Of Ryan Sleevi via Public
Sent: Thursday, January 12, 2017 1:39 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >
Cc: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >
Subject: Re: [cabfpub] Draft CAA motion (3)




On Thu, Jan 12, 2017 at 10:28 AM, Bruce Morton via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

I know there was some discussion about caching. I do think that 1 hour may be a period which is too short. For instance it does not address the case where a CA issues a certificate manually from a secure room/secure server. In these cases, the server will not be able to evaluate a CAA record. I think that this should be raised to 24 hours.


How often does that scenario happen - that you're issuing a server certificate via ceremony (as opposed to an intermediate or root certificate)?


I can appreciate that there might be things that 1 hour would make hard - but I think it is a valid question to ask how often those exceptional situations realistically happen, relative to the riskiness of the proposed solution.



The effective time of 6 months may be too short. For many CAs, they will just start to deploy based on the new ballot. In this case with technical requirements which will impact the issuance of certificates, there should be more time allowed to ensure CAA is deployed effectively. I propose 12 months after the voting period ends.


As with previous discussions about implementation times, can you speak to your specific concerns, rather than hypothetical generalizations? This helps ensure we're picking a reasonable time, not simply an appealing time. I think this is especially important because as proposed, Gerv hasn't touched upon what interaction, if any, this has on cached validations - potentially meaning it's 4 years before domain holders can have any reasonable semblance of security. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170113/c3be46cf/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170113/c3be46cf/attachment-0001.p7s>

More information about the Public mailing list