[gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
ossman at cendio.se
Fri Jul 15 14:32:08 CEST 2016
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 ), 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.)
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?
More information about the Gnutls-help