On Tue, Jul 19, 2016 at 1:31 PM, Pierre Ossman <[email protected]> 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 _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
