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

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?

All the best. Tim.

> On Feb 18, 2014, at 10:30 AM, "Ben Laurie" <benl@google.com> wrote:
> 
> Sorry for long delay.
> 
>> On 5 February 2014 16:19, Jeremy Rowley <jeremy.rowley@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@cabforum.org [mailto:public-bounces@cabforum.org] On
>> Behalf Of Rob Stradling
>> Sent: Wednesday, February 05, 2014 5:37 AM
>> To: certificate-transparency@googlegroups.com
>> Cc: therightkey@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@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@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> 
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey