I don't see the problem with ASN.1. Can't you propose a JSON Encoding Rule standard? Le 28 mars 2014 19:13, "Phillip Hallam-Baker" <[email protected]> a écrit :
> 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] <[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<https://groups.google.com/forum/#!topic/certificate-transparency/T9CDwnsercQ>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 > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
