[gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
ossman at cendio.se
Fri Jul 15 13:53:39 CEST 2016
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:
>> 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.
>> 22.214.171.124.4.1.3126.96.36.199.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.
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?
More information about the Gnutls-help