[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

philliph at comodo.com philliph at comodo.com
Fri Feb 10 17:55:02 UTC 2017


Right now it takes me about 5 years to get a change in the WebPKI. That is three years of getting agreement on the technology, two years to get the infrastructure built out to deploy and then it takes time for the certificate population to rotate.

Now if people would be willing to help shorten the first two periods, I would be a lot more enthusiastic about shortening the third.


> On Feb 10, 2017, at 12:45 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Fri, Feb 10, 2017 at 9:39 AM, philliph at comodo.com <mailto:philliph at comodo.com><philliph at comodo.com <mailto:philliph at comodo.com>> wrote:
> I fail to see how this example shows a security improvement from reducing certificate validity.
> 
> In the case that CABForum declares that certs of a particular type are to be decorated with attribute X, there will naturally have to be a phase in period. The normal practice for such a phase in would be to grandfather all the existing CAs for the period of the phase in and require new entrants to start using the new decoration immediately. So the only practical impact of the phase in period is that clients would have to carry both sets of code for the duration of the phase in. If the period is three years instead of one, they have to carry the legacy grandfather code for 24 extra months.
> 
> That is an argument but it is not a security justification for the proposed change.
> 
> Given that multiple examples were provided, perhaps you might respond specifically to each, rather than the ambiguity as to "this example"
> 
> For example, we know the EKUs are relevant, with respect to CA members ambiguity with respect to what the "Scope of the Baseline Requirements" are, as well as the prohibitions of certain practices for certificates "in scope". So concretely, the introduction of an EKU defines the scope, and thus provides a technical control to identify and reject things which the CA might have interpreted as "out of scope", thereby protecting users.
> 
> Similarly, you've failed to address the matter of domain validation. Do you believe these methods do not improve security at all? Given Comodo's involvement and attention to them, I think that would be a fairly surprising statement for many in this Forum to hear that Comodo does not believe Ballot 169 improves the security through better domain controls. Even more surprising would be if "this argument" referred to CAA, given Comodo's responsibility in providing that draft. Does Comodo believe your specification does not improve the security of the ecosystem, particularly for Subscribers? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/1ce66c1d/attachment-0003.html>


More information about the Public mailing list