Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS authentication

On Wed, Dec 14, 2011 at 10:23 PM, Rob Stradling
<rob.stradling@comodo.com> wrote:
> On Wednesday 14 Dec 2011 17:04:06 Adam Langley wrote:
>> On Wed, Dec 14, 2011 at 5:21 AM, Rob Stradling <rob.stradling@comodo.com>
> wrote:
>> > I've thought of a couple of other ways of wedging the data into the TLS
>> > handshake, although these methods would require more collaboration from
>> > the CAs than you've thus far intended to require (or perhaps expected).
>>
>> Absolutely, putting the audit proof inside the TBSCertificate would be
>> nice and clean. But, while I've no doubt that a CA, such as
>> yourselves, would have no problem handling that, I do fear that
>> getting every CA to implement might be a struggle. Not to mention
>> dealing with folks who have an intermediate CA.
>>
>> Because of this, wedging the data in afterward, while technically
>> obnoxious, is much easier to deploy, assuming that we can get the
>> client compatibility.
>
> How about getting CT to support both approaches (TBSCertificate and "wedging
> the data in afterward") ?
>
> If the TBSCertificate method has better client compatibility, CAs will want to
> support it.  But for those CAs that struggle to support it, "wedging the data
> in afterward" would work well enough for many customers.
>
>> (I also promise to leave extension space for others if we end up using some
>> trick!)
>
> Sounds useful, but I'm not sure what you mean.  (Are you saying what I just
> wrote above, perhaps?)
>
>> Thanks to your hint, I've confirmed that Android < 2.2 rejects
>> certificate chains with superfluous certificates.
>
> Glad to help.
>
>> Thankfully, we can typically wait a while in order to get rid of phones
>
> Huh?  Not sure I follow you.  (Are you saying that people tend to replace
> their phones more often than their desktops/laptops/netbooks, so we don't need
> to support legacy phone OSes/browsers for as long as legacy
> desktop/laptop/netbook browsers?)
>
>> but I'm also taking a look at other ways in which to squeeze the data. My
>> current attempt is running at https://fenton.imperialviolet.org which works
>> on everything that I've tried so far.
>
> I can't see any squeezed data using "openssl s_client -connect
> fenton.imperialviolet.org:443".  Where should I be looking?

Parameters on the signature algorithm :-)

>
>> Of course, none of this is a replacement for a wide scale test on
>> google.com, but that'll have to wait until next year.
>>
>>
>> Cheers
>>
>> AGL
>
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix