[SSL Observatory] certificates for .local names [was: Re: DFN and subordinate CA domain-scoped whitelists]

[Phillip Hallam-Baker]

On Thu, Nov 10, 2011 at 12:36 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net
> wrote:

> On 11/10/2011 12:14 PM, Phillip Hallam-Baker wrote:
> > But the primary responsibility for choice of crypto algorithm and
> strength
> > has always rested with the application developer. I have no control over
> > whether an application uses IDEA or DES or AES. Why expect me to
> > be responsible for your choice of public key strength?
>
> To be clear: are you saying that CAs should be willing to issue
> certificates over EE public keys that are arbitrarily short?
>

No, I am saying that the decision to ban short keys needs to be
the responsibility of the whole industry and not just something
to be left to CA policy because it is only going to stick as
an industry wide commitment.



> What about issuing certificates over public keys that are known to be
> compromised (e.g. public keys corresponding to the etch bad-key blacklist)?
>

Again, more than happy to put in additional controls to catch
known problems. But that is not the same as accepting
responsibility.

Let us imagine for the sake of argument that there was a weak key
issue that was not completely trivial. Say the work factor of the key
was 2^64 so that the key is definitely unsafe but checking it is
going to be very expensive. And let us say that the CSRs are
indistiguishable from CRSs from other software and it is going to
require spending $50 worth of CPU to check out 100,000 keys.

Now if someone was to make that kind of mistake I would
expect that the CAs would be anxious to make sure that
our customers are secure but that does not mean accepting
responsibility for fixing the problem and paying the $5 million
for the necessary CPU time. That is very clearly the application
provider responsibility.


Now what would happen if the application provider refused to
pay up would be another issue. But even if the CAs end up
accepting the cost of cleanup they are not accepting
responsibility.

What responsibility do you think a reasonable CA has to its subscribers
> if it becomes aware that their secret key material may be compromised?
>
> What responsibility do you think a reasonable CA has to its relying
> parties if it becomes aware that a secret key which they have certified
> may be compromised?


See above. The primary responsibility for making sure the crypto is
strong enough has to fall on the application provider.

The CAs should provide a backup but this does not absolve the
application designer from making the right choice.


What I am objecting to here is that this exercise seems to only
ever be interested in holding CAs accountable.


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111110/c25f9261/attachment.html>