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

[Pierre Ossman]

On 15/07/16 13:43, Nikos Mavrogiannopoulos wrote:
> On Fri, Jul 15, 2016 at 12:01 PM, Pierre Ossman <ossman at cendio.se> wrote:
>> Hi,
>>
>> I was looking at gnutls_x509_crt_get_dn() as a way to generate string
>> representations of DNs according to RFC4514. But there are two things that
>> strike me as being out of spec:
>>  - The order of RDNs is wrong. GnuTLS outputs them first-to-last, but
>> RFC4514 states:
>
> It seems you are right, indeed, the strings output by gnutls is first
> to last. Would you be interested in fixing that, or contribute a unit
> test for various encodings and their expected output string (similarly
> to tests/base64.c)?
>

I could have a look. But it would most likely be a few weeks away. I'm 
just about to head off for some time off.

>>  - The oid list includes some things not in the IANA registry. E.g.
>> 1.3.6.1.4.1.311.60.2.1.3 and XmppAddr.
>
> Is that really an issue?
>

It can be. See below.

>> 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.

Regards
-- 
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?