On 28 March 2014 18:27, Rick Andrews <[email protected]> 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:[email protected]] > Sent: Friday, March 28, 2014 11:14 AM > To: Rick Andrews > Cc: Eran Messeri; Rob Stradling; [email protected] > > > 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 <[email protected]> > 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:[email protected]] On Behalf Of Eran Messeri > Sent: Friday, March 14, 2014 3:01 AM > To: Phillip Hallam-Baker > Cc: Rob Stradling; [email protected] > 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 <[email protected]> > wrote: > > On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/trans > > > > > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > -- Certificate Transparency is hiring! Let me know if you're interested. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
