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

Nikos Mavrogiannopoulos nmav at gnutls.org
Fri Jul 15 14:16:25 CEST 2016


On Fri, Jul 15, 2016 at 1:53 PM, Pierre Ossman <ossman at cendio.se> wrote:
>>> The oid list also seems a bit arbitrary, which could make
>>> interoperability a
>>> bit annoying. :/
>> It is based on what we currently see in PKIX certificates. What kind
>> of interoperability are you concerned of?
> Our usage is to transport the subject name over an existing system in place
> of the user name. Hence the need to encode it in to some string form. Rather
> than just do a hex encode, we figured RFC4514 would fit the purpose and also
> make the encoded result fairly readable (in logs and such).
>
> But for it to work the receiver needs to be able to decode it back to some
> data structure. In practice that means it needs to know more attribute types
> than the sender. So if the sender would e.g. send
> "XmppAddr=foo at example.com", then a strict RFC 4514 receiver would have no
> idea how to turn that back in to an ASN.1 structure for comparison with the
> local database.
>
> I'm starting to think that the safe approach is that the sender only uses
> the minimal list specified in RFC 4514.

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?

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/issues/111



More information about the Gnutls-help mailing list