On 15/07/16 14:16, Nikos Mavrogiannopoulos wrote:
That makes sense, although I'm not sure that you could indeed use these to go back and forth to ASN.1, for the reasons you mentioned. Even if we fix the order (which is a good thing, so I've tracked that in [0]), we will always want to make human-readable common fields present in certificates, so there will be non-standard fields in the gnutls' output functions. That could be addressed however by having the reverse of gnutls_x509_dn_oid_name() made available which will translate a known name to an OID. Would that be sufficient?
As a back up plan, yes. But that would mean that we specify the system as "send the DN encoded as GnuTLS version x.y.z does it", rather than a formal standard like RFC4514. The latter would be preferred if possible. But it isn't perfect, so we are still tossing around ideas.
As far as RFC4514 vs other human-readable, you could mark the OIDs in the list as being RFC4514 compliant or not. Separate functions could then be provided depending on if you want something with strict adherence to the RFC, or just something nice to present to the user.
(Btw. if I'm reading the code correctly then GnuTLS currently cannot fully parse its own output. Handling of the #<hex> fallback for values currently just returns a parse error.)
Rgds -- Pierre Ossman Software Development Cendio AB https://cendio.com Teknikringen 8 https://twitter.com/ThinLinc 583 30 Linköping https://facebook.com/ThinLinc Phone: +46-13-214600 https://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
