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

[Nikos Mavrogiannopoulos]

On Tue, Jul 19, 2016 at 1:31 PM, Pierre Ossman <ossman at cendio.se> wrote:
>> That could be an option, but we have to see who would be the consumer
>> of such API. Why would this be used today? DNs are being deprecated
>> over PKIX and the subjectAlternativeName is the only way to specify
>> names (for end-certificates) today. Are there use cases of certificate
>> DNs today that I am missing?
> Except for ours, none that I know of. And you're right, the proper way to
> handle this is using more structured data. So any use case would most likely
> be similar to ours, where you're trying to make things work over an existing
> string based system.

Based on your previous comments, I have made some improvements in the
DN handling API, but I haven't yet made changes for the parsing in
reverse of the rdn field. It is more complicated as it seems, since it
affects both directions, DER->string and string -> DER, and the former
is not straightforward to achieve. So will not proceed with the
reversing of the output for DER->string (I've attached a demo patch at
[0]), unless of course you send patch that handles both string->DER
and DER->string in a clean way.

Nevertheless, I've given a second look at RFC4514, and noticed that
cannot be used the way you intend to. If you see section 2.2 the
RelativeDistinguishedName DER->string mapping is in any (arbitrary)
order. While it is not common to have DNs with multiple
RelativeDistinguishedName elements in a sequence, it is a case that
any DER->string and string->DER mappings cannot handle in a
deterministic way. My advice... stay away from the DN :)

regards,
Nikos

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