[cabfpub] Draft CAA motion (3)

Dean Coclin Dean_Coclin at symantec.com
Fri Jan 13 16:54:38 MST 2017


Sure, I get that. I was just cautioning others in case they were planning on disclosing their product roadmaps ;-)

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Friday, January 13, 2017 4:22 PM
To: Dean Coclin <Dean_Coclin at symantec.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>; Jeremy Rowley <jeremy.rowley at digicert.com>
Subject: Re: [cabfpub] Draft CAA motion (3)

 

I appreciate your attention to the Bylaws, but I would suggest Jurgen's response is a clear example where "compliance with root programs' expectations" != "service offerings"

 

Of course, if the answer is "We'll be offering other services" rather than "We'll be complying with various other root-program imposed requirements", then I agree - and it also becomes a simpler matter to suggest "As a CA, security must always be the top priority" :)

 

On Fri, Jan 13, 2017 at 1:18 PM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:

Just a friendly reminder that our bylaws specifically prohibit certain discussions:

 

all participants agree not to discuss or exchange information related to:

(a) Pricing policies, pricing formulas, prices or other terms of sale;

(b) Costs, cost structures, profit margins,

*(c) Pending or planned service offerings*

(d) Customers, business, or marketing plans; or

 

 

So a question like, “if you’re not doing CAA, what else are you doing”, may fall into (c) above.

 

From: Public [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> ] On Behalf Of Ryan Sleevi via Public
Sent: Friday, January 13, 2017 4:11 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Cc: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >; CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >


Subject: Re: [cabfpub] Draft CAA motion (3)

 

Jeremy,

 

Was it intentional that you avoided answering on behalf of DigiCert?

 

As to your remarks around Bruce's answer - the original suggestion for 12 months came from concern for "many CAs", without stating whether or not Entrust was among that set, or who else might be. The follow-up response indicated "We planned things and didn't plan for CAA", but doesn't expand on what those things are or why they might be more important/relevant/useful to deploy versus CAA.

 

I understand the suggestion of 12 months is appealing. So is 18 months or 24 months or never. Those are all quite appealing for CAs, no doubt. The question from at least this browser is: What gets dropped if we keep it at 6 months? Because Bruce's argument is one on priorities - that there are a number of things competing for the same resources - and so we, as a community, need to assess what the priorities for the ecosystem should be, and whether those things need to be reprioritized or to allow the request that CAA (despite years of discussions) be deprioritized again.

 

I'm not keen to kick this can down the road, given the level of discussion we've had, but if the argument is that 6 months isn't realistic, more details about why need to be shared than simply "I propose 12 months"

 

On Fri, Jan 13, 2017 at 1:05 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

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 <mailto:sleevi at google.com> ] 
Sent: Thursday, January 12, 2017 3:50 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org <mailto: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://cabforum.org/pipermail/public/attachments/20170113/83b9d73b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170113/83b9d73b/attachment-0001.bin>


More information about the Public mailing list