On 3 March 2015 at 16:02, Russ Housley <[email protected]> wrote: > Melinda: > > > First, I need to apologize for being largely checked out the > > past while - I've been down with a particularly virulent flu > > and am still largely flattened by it. I'll do better. > > I'm sorry you were stricken, but I'm glad to hear you are feeling much > better. > > > Second, taking my chair hat off, a couple of comments on the > > syntax question: I'm not sure that there have been any > > technical arguments made for why either approach must be > > excluded, which would be the first place to start, I think. > > 5246 definitely does not say that that syntax must not be used > > for anything else, ever. What it says is: > > > > "The purpose of this presentation language is to document TLS only; it > > has no general application beyond that particular goal." > > > > Because you've wanted to treat this legalistically I think it's > > reasonable to point out that the phrase "has no general application" > > does not exclude the use of the same syntax to describe what > > are TLS-coupled data structures, unless you're arguing that > > CT logging of TLS certs would be a "general application." Even so, > > you don't have to look through many IETF specifications to find > > instances of later protocols violating some of the constraints written > > into earlier specifications - for example, in RSVP-TE extensions to > > RSVP. So, I think that's a tough path to follow. > > > > Frankly, in the absence of compelling technical arguments either > > way, my personal inclination is to privilege implementation. Again, > > that's my *personal* inclination. In the meantime, if there's a > > compelling technical argument against this encoding, it's definitely > > time to make it. We do need to make progress and not keep > > going over the same ground and arriving at same outcomes. > > At the time that certificate extensions were invented, the OCTET STRING > wrapper was used so that the ASN.1 decode would not fail if an unsupported > extension was encountered. Some people complained about the performance > hit that that additional wrapper imposed on universally supported > extensions, but this is the syntax that was chosen by ITU-T in X.509 > version 3. I do not recall any discussion at that time about allowing the > OCTET String to contain anything other than an ASN.1 DER encoded structure. > > RFC 2459, section 4.2 says: "Each extension includes an OID and an ASN.1 > structure." That remains in RFC 5280. >
6962 and 6962-bis are compliant with 5280. The ASN.1 structure that is included is an OCTET STRING. The value of that OCTET STRING is the TLS structure. The alternatives are: a) Encode SCTs different ways for different contexts. This seems like pointless complexity. b) Change SCTs to ASN.1 structures, and wrap these in a TLS opaque when presented in a TLS extension. This is exactly analogous to the current situation, and analogous arguments can be made for/against it. I hope no-one is arguing for a), leaving us with b), and no convincing reason to choose it over the current format on the basis of what the standards say (or vice versa), as far as I can see. Given that since Jan 1 2015 significant numbers of certificates have been deployed using the existing format, I suggest that the appropriate resolution is to continue with the format that is already deployed.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
