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

[Phillip Hallam-Baker]

Yes, the world does have more things than browsers and I strongly suspect
that most of the applications driving the bizarre demand for 512 bit certs
will turn out to be that type of application.

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?

Relying applications should reject cert chains with a key strength of less
than 1024 bits and they should ideally have code in there to disable use of
cert chains with a key strength of less than 2048 past some drop-dead date
in the hopefully not to distant future and reject SHA-1 certs at some point
as well.


I am quite happy to contribute to the industry effort to inform people on
best practices. What I will not accept is your attempt to lay the blame for
every fault you see in the use of crypto at my door. All that the CA does
is to make statements about the holder of a private key corresponding to a
public key. Relying parties can see for themselves that the public key is
weak.

The reason that I do not want to take responsibility for this is that I can
only control the certs that I issue. The only way to make the Internet
safer is for application software to stop accepting use of bad
cryptography. I want to see platforms stop supporting use of MD4, MD5 and
all the rest of the obsolete junk crypto in their platforms. That is going
to cause existing code to break so they are going to be very reluctant to
do it.

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.

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.


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.


On Wed, Nov 9, 2011 at 2:51 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:

> On 11/09/2011 09:03 AM, Phillip Hallam-Baker wrote:
> > On Wed, Nov 9, 2011 at 11:40 AM, Daniel Kahn Gillmor
> > <dkg at fifthhorseman.net>wrote:
> >
> >>
> >> Am i wrong in thinking that this makes the "please recount the number of
> >> CAs" concern seem like a distraction from deeper issues?
> >>
> >
> > No, not at all.
> >
> > If you want this to be a productive and constructive effort to make the
> CA
> > system work better then there has to be trust on both sides.
> >
>
> That's pretty rich coming from Comodo!
>
> > If we have people misrepresenting results to make false claims then CAs
> > have to think twice before they respond to anything knowing that it may
> be
> > used for 'gotcha' purposes later on.
> >
>
> The count given by Peter and the EFF makes sense based on the
> explanations on this list.
>
> Please show us all that the data collected is either invalid or that you
> have a different dataset that somehow supersedes it.
>
> >
> > Remember that currently there are no industry wide criteria for issue of
> DV
> > certs. We should have some very soon, but for fifteen years it was left
> to
> > individual CAs to make policy. Now the reason that Melih and I convened
> the
> > meeting that led to the formation of the CA-Browser forum was that we
> > recognized that there was a problem here that we both wanted to fix.
> >
>
> ssladmin at domain.tld is still pretty much the way that people issue DV
> certs. Hilariously bad - I should know, that's my default choice for a
> new email address these days.
>
> > There are many CAs that share the same goal of making the Internet trust
> > system more reliable and trustworthy. But don't present this as something
> > that is exclusively the fault of CAs. It is not (just) the fault of the
> > goalkeeper when the ball ends up in the back of the net.
> >
> >
>
> When will Comodo come clean about the entire Comodogate scandal?
>
> This is almost entirely the fault of the CAs. What checks and balances
> have you built to prevent these kinds of compromises from happening in
> the first place?
>
> > I don't actually see any problem with .local domains using SSL. The real
> > problem comes from browsers telling end users that this means a site is
> > 'safe'. So one approach would be to tell browser providers that when SSL
> is
> > used at .local sites that the user should never see a padlock icon or any
> > other security indicator in primary chrome.
>
> I guess you just answered my last question, eh?
>
> The world is more than browsers. This kind of thinking is why the fault
> for a great deal of security failures rests on the shoulders of the CAs.
>
> Sincerely,
> Jacob
>



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