Re: [Trans] RFC6962 BIS Log file encodings.

On 28 March 2014 18:27, Rick Andrews <Rick_Andrews@symantec.com> wrote:
> I understand that there are problems with ASN.1 and many people don’t like
> it, but if we’re talking about X.509 certificates we have to use ASN.1. All
> of our code for putting blobs into a cert work by defining the structure
> using ASN.1. Yes, we can add a blob that has some other encoding, but it’s
> more difficult.
>
>
>
> If the encoding were ASN.1, it might make adoption more straightforward.

The problem is, there's no right answer here: strictly, the "most
correct" way of including an SCT is as a TLS extension - and that's
why we chose TLS encoding for SCTs. Whatever we do, it seems someone
will be unhappy. And at least TLS encoding is less complicated than
DER.

>
>
>
> -Rick
>
>
>
> From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
> Sent: Friday, March 28, 2014 11:14 AM
> To: Rick Andrews
> Cc: Eran Messeri; Rob Stradling; trans@ietf.org
>
>
> Subject: Re: [Trans] RFC6962 BIS Log file encodings.
>
>
>
> The encoding isn't ASN.1 so using ASN.1 schema is a terrible idea.
>
>
>
> Putting data in certificates does unfortunately lead to the risk of ASN.1.
>
>
>
> One of the reasons I developed JSON-BCD was I could see this going to happen
> and I would much prefer the JSON style approach over any further investment
> in ASN.1.
>
>
>
>
>
>
>
> On Fri, Mar 28, 2014 at 1:31 PM, Rick Andrews <Rick_Andrews@symantec.com>
> wrote:
>
> In addition, our ASN.1 experts have asked for the syntax to be described in
> “ASN.1-like” syntax, as is used in RFCs 3280 and 5280.
>
>
>
> For example, 3280/5280 defines an Extension like this:
>
>
>
> Extension  ::=  SEQUENCE  {
>
>      extnID      OBJECT IDENTIFIER,
>
>      critical    BOOLEAN DEFAULT FALSE,
>
>      extnValue   OCTET STRING  }
>
>
>
> so the extnValue is defined as an OCTET STRING, yet 6962 says “…encoding the
> SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and
> inserting the resulting data in the TBSCertificate as an X.509v3 certificate
> extension…”. The ASN.1 folks say it’s not clear if that means that the
> Extension contains the OCTET STRING data type (for extnValue) and length
> followed by another OCTET STRING data type identifier and length of the SCT.
> Or is the second OCTET STRING identifier redundant?
>
>
>
> Those updating existing cert generation code will probably be dealing with
> ASN.1 compilers, so a precise definition of structures in ASN.1-like syntax
> will go a long way. In addition, defining OIDs as arc plus extension (like
> this: id-kp-serverAuth  OBJECT IDENTIFIER ::= { id-kp 1 }) would help.
>
>
>
> -Rick
>
>
>
> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Eran Messeri
> Sent: Friday, March 14, 2014 3:01 AM
> To: Phillip Hallam-Baker
> Cc: Rob Stradling; trans@ietf.org
> Subject: Re: [Trans] RFC6962 BIS Log file encodings.
>
>
>
> I strongly support clarifying the description of the file format. When I
> started implementing aspects of RFC6962 (with no background in TLS encoding
> or ASN.1) it was very unclear.
>
> From other posts on the list it seems this was unclear to others as well.
>
>
>
> On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker <hallam@gmail.com>
> wrote:
>
> On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling <rob.stradling@comodo.com>
> wrote:
>
> (Inspired by RFC5280 Appendix C)
>
> Would it help to include one or more example SCTs in the text?
>
>
>
> I think we definitely need that for Proposed. But right now I am trying to
> see how complete the description is.
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>
>
>
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Certificate Transparency is hiring! Let me know if you're interested.