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

[Ben Wilson]

It's like a cross between the Tragedy of the Commons and the Wild West.  The
wide open space of the Internet without controls allows anyone to trash it
without taking on responsibility for their actions.  

 

From: Phillip Hallam-Baker [mailto:hallam at gmail.com] 
Sent: Thursday, November 10, 2011 6:59 PM
To: ben at digicert.com
Cc: EFF Observatory
Subject: Re: [SSL Observatory] certificates for .local names [was: Re: DFN
and subordinate CA domain-scoped whitelists]

 

Just to re-iterate, 

 

CAs stand willing ready and able to help here. But a big part of the reason
that we have issues here is that the lines of responsibility are not clear.

 

It is like when you have two parents who both think the other is watching
the child. That is when problems arise.

 

 

We need to clarify these lines of responsibility because we have at least
two further cryptographic algorithm turnovers that will have to happen in
the near future (after which the issue should only really arise if there is
a major defect in one of the algorithms.). These are the RSA1024 turnover
and the SHA-1 turnover.

 

Who has the speaking stick for those probably matters much less than that
everyone knows who has it and they have at least some coercive power.

 

On Thu, Nov 10, 2011 at 7:50 PM, Ben Wilson <ben at digicert.com> wrote:

I have to agree with Phillip.  Many application developers don't know how to
properly integrate PKI into their systems.  For instance, some email system
providers still don't know what S/MIME is.  Some applications ignore Policy
OID processing or simply skip revocation checking or chain processing or
whatever.  Gate keeping is best performed by a programmable system that can
determine whether the signed blob is appropriate for its intended purpose.
But I'm not defending all CAs either.  I've seen many examples of strange
blobs being passed off as certificates, but relying party systems need to be
able to reject these if they don't satisfy the criteria needed for
trustworthy processing.


On 11/10/2011 12:14 PM, Phillip Hallam-Baker wrote:

>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/20111111/03e1a8aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5461 bytes
Desc: not available
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111111/03e1a8aa/attachment.bin>