[gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?

[Pierre Ossman]

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?