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; 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. 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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
