On 11/03/15 15:31, Stephen Kent wrote:
Ben,
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 use of OCTET STRING is only superficially compliant;
<silliness>
How about we base64-encode the SCT and put it in a PrintableString
instead? ;-)
</silliness>
it is inconsistent with all of the prior X.509 extensions of which I am
aware, and with the text that Russ Housley cited in his message on 3/3.
How does putting an RFC5246-encoding-rules SCT into an OCTET STRING
violate the sanctity of ASN.1 any more than the RFC5280 practice of
putting an RFC3986 URI into an IA5String does?
Or, to put it another way, why didn't the RFC5280 authors insist on
coming up with a different "pure ASN.1" format for encoding the
components of a URI?
Rob's observation about what X.680 says is not relevant to this debate:
the issue is not what an OCTET STRING is allowed to contain in general,
but what is the syntax of an X.509 extension.
The alternatives are:
a) Encode SCTs different ways for different contexts. This seems like
pointless complexity.
to me it seems entirely appropriate.
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 agree that this is unattractive.
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.
I am arguing for a).
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.
Experience gained with 6269 is relevant, as it presumably shows that
implementers have been
able to make the current syntax work. But, an experimental RFC represent
does not establish
a precedent relevant to a standards track RFC that precedes it. In many
(most?) cases
Experimental RFCs receive little review before being published. If the
IETF were to agree that
implementations based on such RFCs establish design precedents for
standards track RFCs,
especially when they conflict with existing, standards track RFCs, this
would encourage publication
of experimental RFCs as a way to game the system.
Steve
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
