Erwann,
Thanks for the pointers to the IEEE work; we'll see how that progresses
and whether the PKI aspects of it transition to the IETF.
Also thanks for the acknowledgement that ASN.1 is considered
the preferred syntax for X.509 extensions.
Steve
Bonsoir Stephen,
2015-02-27 22:16 GMT+01:00 Stephen Kent <[email protected]
<mailto:[email protected]>>:
Erwann,
The "TLS" syntax/notation is also used to describe
certificates and messages in ITS world. It's very bad, but
that's not RFC5246 authors's fault.
What is the "ITS" world? And is it under the IETF standards
umbrella? if not, then this is
not a good rationale for veering from the statement in 5246.
"Intelligent Transport System". Cars, trucks, motorbikes, tramways,
trains, road equipment, ... See IEEE1609.2 and ETSI TS103097 if you're
curious :)
That's not (yet) under IETF umbrella. Point taken.
X.509 permits the inclusion of anything in an extension, as
long as it's enclosed in something that has an ASN.1+DER
representation, whence the double OCTET STRING sometimes
found. That's not new to CT.
True, but I think that is not commonly done in standard
extensions. Do you have some examples
that counter my perception? In my experience, people developing
extensions for
X.509 usually try to avoid cramming arbitrary data into an OCTET
string.
You're right again. I can't think of a single extension except
SignedCertificateTimestampList defined in anything other than ASN.1.
When working around X.509, ASN.1 is natural.
Going back into "silent lurker" mode...
--
Erwann.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
