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

[Daniel Kahn Gillmor]

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?

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

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?

> I do not accept responsibility for changes that I don't have the power to
> enforce. If the industry wants to make me crypto algorithms Tzar and allow
> me to pick algorithms for them then I will. But I can't accept primary
> responsibility otherwise.

No one is asking you (or anyone) to accept "primary responsibility";
they're asking CAs to accept responsibility for the certificates that
they issue.  Something along the lines of "we reasonably believe that
party X is the only party in control of the secret key material that
corresponds to public key Y".  Granted, you can't prevent party X from
sharing the secret key material with whoever they want.  But doing a
baseline check that says "hmm, i can brute-force this 64-bit public key
using my mobile phone -- it's probably not something i should be
certifying" seems like a good thing to do.

> If we want to make constructive progress on this we need to have an
> industry discussion and make a decision as an industry to move forward.
> There are two forums where such a discussion could take place. One is IETF
> and the other is CA-Browser forum.

The CA-Browser forum is inappropriate because there are more consumers
of X.509 than browsers.  If you want to propose an IETF WG list to move
this discussion to, please propose a location and set Mail-Followup-To,
so this list can go back to datamining the observatory and discussing
the details.

> For all the faults you see in the SSL/CA system the fact is that it is the
> only application of public key cryptography that has been successful on the
> Internet. Actual use of S/MIME, PGP and IPSEC remains negligible.

The widespread deployment of X.509/CA infrastructure is *precisely* the
reason that it's important to make sure that problems are identified,
acknowledged, and fixed.   It's not a magic wand to make the problems
disappear.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111110/d1820656/attachment.sig>