[cabfpub] Thoughts on reducing SCT sizes (was Re: Updated Certificate Transparency + Extended Validation plan)

[Rob Stradling]

On 06/02/14 10:11, Erwann Abalea wrote:
> Le 05/02/2014 13:36, Rob Stradling a écrit :
> [...]
>> Agreed.  Time for some back-of-an-envelope sums.  For SCT v2, if we were
>> to pack in the data as tightly as possible I reckon we could cut it down
>> to as little as...
<snip>
> We're moving again away from ASN.1.

Well, we're staying away from ASN.1.  The SCT v1 format doesn't use 
ASN.1.  ;-)

> Save 2 more bits by having the sct_version set by the extension OID.

There could be multiple SCTs in the certificate extension, and there's 
no guarantee that each SCT will be the same version.

> Later, change the encoding of the transmitted certificates from DER to
> UPER (change it internally back to DER to verify the signature).

This could go on the wishlist for TLSv1.3, but how would you do it for 
<=TLSv1.2 without breaking compatibility with existing TLS clients?

>> 4. Use the Ed25519 signature scheme instead of ECDSA.  ECDSA signatures
>> using a P-256 key seem to be 72 or 73 bytes, whereas Ed25519 signatures
>> are 64 bytes.  Save 8 or 9 bytes per SCT.
>
> This is not between Ed25519 and ECDSA, but between ASN.1+DER encoding
> and pure binary.
> An ECDSA P256 signature is also 64 bytes long (2 integers modulo a 256
> bits quantity), but they are both encoded as INTEGERs (+2 or +3 each),
> enclosed in a SEQUENCE (+2), and encapsulated in a BITSTRING (+3).

Ah, good point.  Thanks!

>> Also, for Ed25519, omit the 2 bytes containing the hash algorithm and
>> signature algorithm from the "digitally-signed struct" header.  Save 2
>> bytes per SCT.
> That's also doable in ECDSA. You're just trading flexibility with space.

Sure.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online