Re: [keyassure] publishing the public key

A much better saving is to use the tls option that allows for fast rekey by means of a kerberos like ticket stored on the client side.

That approach means the client does one key exchange and that is leveraged over multiple http sessions.

The cert is only a kb, self signed certs are less and your main saving would be not having the signature. Looking at the tls key exchange, what matters is packets, not really bytes. I dont think you will find certs vs keys saves a packet.

Sent from my iPad

On Feb 14, 2011, at 4:46, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:

> On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote:
>> Hi,
>> 
>> In draft-dane-04 [1] one can currently only publish either a signature
>> or a certificate in the DNS. That is the only allowed formats of the
>> resource record are as specified in section 2.2
>> 
>>  1 -- Hash of an end-entity certificate
>>  2 -- Full end-entity certificate in DER encoding
>>  3 -- Hash of an certification authority's certificate
>>  4 -- Full certification authority's certificate in DER encoding
>> 
>> Why not publish the only piece of the certificate that is important in
>> public key cryptography: the public key. ( This is what WebID does
>> currently ) This should be shorter than the certificate, and though it
>> will be longer than the signature, it will be a lot more useful, tying
>> the publisher much less to a particular serialisation format. So you
>> reduce the PGP/X509 disagreements.
> 
> Unfortunately TLS requires sending the full certificate. Yes, one could
> define a new certificate type that contained just the public key, but
> that would require a IETF consensus (RFC through TLS working
> group[1]).
> 
> Then one would define new DANE ceritifcate type (3 [2] or 5/6) to
> match that.
> 
> <snip idea of certificate URLs>
> 
> I don't think that would be possible to use without new certificate
> type either.
> 
> As for bandwidth, sure it would save some. One can send well-secured
> key in roughly 80 bytes total (including CertificateType extension).
> Modern X.509 certs are far larger[3], even if restricted to bare
> minimum fields.
> 
> As for what this would be useful for: If the raw key format would
> be easily parsed, it would save lots of tricky ASN.1 and X.509
> parsing (yes, there are libraries for that)
> 
> 
> 
> 
> [1] Not entierely accurate, it is RFC approved by IESG (and they'll
> consult TLS WG).
> 
> [2] Since those 4 types could be collapsed to 2 (2 of those require
> second byte to be zero and 2 require nonzero second byte)
> 
> [3] There's also subtle performance issue there. Those certificates
> can be so large that TCP windows get overflowed. As consequence,
> either one has to break TCP spec (many sites do this) or suffer
> a latency hit.
> 
> -Ilari
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure