[cabfpub] Thoughts on reducing SCT sizes (was Re: Updated Certificate Transparency + Extended Validation plan)
Rob Stradling
rob.stradling at comodo.com
Thu Feb 6 10:32:51 UTC 2014
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
More information about the Public
mailing list