[cabfpub] [therightkey] Thoughts on reducing SCT sizes (was Re: Updated Certificate Transparency + Extended Validation plan)
Ben Laurie
benl at google.com
Tue Feb 18 16:58:56 UTC 2014
On 18 February 2014 15:37, Tim Moses <tim.moses at entrust.com> wrote:
> Ben - Will Chrome deny EV status to a certificate with too few SCTs, or will it grant EV status as long as at least one of its SCTs is from a log that remains in the program?
It will deny.
>
> All the best. Tim.
>
>> On Feb 18, 2014, at 10:30 AM, "Ben Laurie" <benl at google.com> wrote:
>>
>> Sorry for long delay.
>>
>>> On 5 February 2014 16:19, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
>>> Table 1 of the plan document said both 3 SCTs and 4 SCTs for 27 months.
>>> Until there is clarification on which is required, 3-4 is the best
>>> representation of the requirement. I'm hoping Ben meant 15-27 months = 3 and
>>> 27 = 4, but it's not clear from the document.
>>
>> Yes, that's exactly what I meant.
>>
>>>
>>> Jeremy
>>>
>>> -----Original Message-----
>>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
>>> Behalf Of Rob Stradling
>>> Sent: Wednesday, February 05, 2014 5:37 AM
>>> To: certificate-transparency at googlegroups.com
>>> Cc: therightkey at ietf.org; CABFPub
>>> Subject: [cabfpub] Thoughts on reducing SCT sizes (was Re: Updated
>>> Certificate Transparency + Extended Validation plan)
>>>
>>>> On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley wrote:
>>>> Three or four proofs for a 27 month certificate is way too many.
>>> <snip>
>>>> Adding 400 bytes per certificate will make EV certificates unusable by
>>> entities concerned with performance.
>>>
>>> The updated CT+EV plan requires three SCTs for a (maximum length) 27-month
>>> EV certificate, not four. 400 bytes for three SCTs is about right though.
>>>
>>> Assuming RFC6962-compliant v1 SCTs that contain no SCT extensions and are
>>> signed using ECDSA and a P-256 private key, then, including all of the ASN.1
>>> fluff for the SCT List certificate extension, I calculate that it'll be...
>>>
>>> 140 or 141 bytes to embed 1 SCT
>>>
>>> 261 to 263 bytes to embed 2 SCTs
>>>
>>> 380 to 383 bytes to embed 3 SCTs
>>>
>>> For (non-EV) validity periods between 27 and 39 months:
>>> 499 to 503 bytes to embed 4 SCTs
>>>
>>>> On 04/02/14 17:52, Adam Langley wrote:
>>>> <snip>
>>>> We should make the SCTs as small as possible
>>>
>>> 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...
>>>
>>> 84 bytes to embed 1 SCT
>>>
>>> 159 bytes to embed 2 SCTs
>>>
>>> 231 bytes to embed 3 SCTs
>>>
>>> 303 bytes to embed 4 SCTs
>>>
>>> Here's how...
>>>
>>> 1. Use a shorter OID for the SCT List extension. Perhaps CABForum could
>>> define 2.23.140.n (with n < 128). Save 6 bytes.
>>>
>>> 2. The first 2 bytes of the SignedCertificateTimestampList structure are its
>>> total length. Since this can be calculated from the OCTET STRING length,
>>> these 2 bytes could be omitted. Save 2 bytes.
>>>
>>> 3. Pack the SCT fields into as few bytes as possible for the common case,
>>> whilst retaining options for future expansion. Save 37 bytes per SCT.
>>> Replace...
>>> (1 byte) Version sct_version;
>>> (32 bytes) LogID id;
>>> (8 bytes) uint64 timestamp;
>>> (2+? bytes) CtExtensions extensions;
>>> ...with...
>>> (2 bits) sct_version (00=v1; 01=v2; 10,11=unassigned)
>>> (2 bits) log_id_type (00=SHA-256(log_public_key);
>>> 01=1-byte Registered Log ID;
>>> 10=2-byte Registered Log ID;
>>> 11=4-byte Registered Log ID)
>>> (2 bits) timestamp_size (00=8-bytes;
>>> 01=6-bytes;
>>> 10=5-bytes;
>>> 11=4-bytes)
>>> (1 bit) extensions (0=CtExtensions is present;
>>> 1=CtExtensions is absent)
>>> (1 bit) signature_type (0=digitally-signed struct;
>>> 1=raw Ed25519 signature)
>>> For the common case:
>>> (1 byte) Registered Log ID
>>> (4 bytes) Timestamp (seconds, not milliseconds)
>>>
>>> 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.
>>> 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.
>>>
>>> --
>>> Rob Stradling
>>> Senior Research & Development Scientist
>>> COMODO - Creating Trust Online
>>> _______________________________________________
>>> Public mailing list
>>> Public at cabforum.org
>>> https://cabforum.org/mailman/listinfo/public
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>> _______________________________________________
>> therightkey mailing list
>> therightkey at ietf.org
>> https://www.ietf.org/mailman/listinfo/therightkey
More information about the Public
mailing list