Re: [Trans] Bad Technical Decision: Closing out the SCT encoding discussion

[Rob Stradling <[e-mail]>]

On 13/03/15 21:15, Rob Stradling wrote:
> On 13/03/15 21:05, Stephen Farrell wrote:
>> On 13/03/15 20:58, Rob Stradling wrote:
>>> On 13/03/15 20:25, Stephen Farrell wrote:
>>> <snip>
>>>> And if we interpret 5280 strictly and conclude that is still a
>>>> good plan then the question would be what to do about the SCT
>>>> encoding, which could be to do something hacky like prepending
>>>> another OCTET STRING tag and a length I suppose,
>>>
>>> Stephen, RFC6962 does precisely that, and the current 6962-bis text aims
>>> to do the same.
>>
>> Really?
>
> Really.  That's what all the current implementations of RFC6962 are doing.

It probably doesn't help that RFC6962 has two definitions of 
"SignedCertificateTimestampList", one using ASN.1 and one using TLS 
encoding rules.

        SignedCertificateTimestampList ::= OCTET STRING

         struct {
             SerializedSCT sct_list <1..2^16-1>;
         } SignedCertificateTimestampList;

This issue is addressed in 6962-bis -07.

>> I though the extnValue was just the SignedCertificateTimestampList
>> and did not contain yet another OCTET STRING tag? That how I read
>> 6962 anyway.
>
> Some other folks read it that way too, apparently.
>
> Hence http://trac.tools.ietf.org/wg/trans/trac/ticket/14
>
>> S.
>>
>>>
>>> Adding yet another OCTET STRING would turn it into an OCTET STRING
>>> inside an OCTET STRING inside an OCTET STRING!
>>>
>>> I'd be surprised if Russ or Steve Kent would consider that to be any
>>> better than the current plan (an OCTET STRING inside an OCTET STRING).
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.