> On 20 Jan 2021, at 20:07, Jacob Champion <pchampion@vmware.com> wrote:
>
> On Mon, 2021-01-18 at 11:23 +0100, Daniel Gustafsson wrote:
>> + /* use commas instead of slashes */
>> + X509_NAME_print_ex(bio, x509name, 0, XN_FLAG_SEP_COMMA_PLUS);
>> I don't have strong opinions on whether we shold use slashes or commas, but I
>> think it needs to be documented that commas are required since slashes is the
>> more common way to print a DN.
>
> There's also a XN_FLAG_RFC2253 flag, which claims to print in an RFC-
> compatible escape system. (It includes XN_FLAG_SEP_COMMA_PLUS.) I think
> NSS uses a similar RFC-based escape scheme, but I haven't checked to
> see whether it's fully compatible.
>
> I think you'll want to be careful to specify the format as much as
> possible, both to make sure that other backend TLS implementations can
> actually use the same escaping system and to ensure that user regexes
> don't suddenly start matching different things at some point in the
> future.
Reading more on this it seems we would essentially have to go with RFC 4514, as
it's the closest to a standard which seems to exist. Having done a lot
research on this topic, do you have a gut feeling on direction?
The OpenSSL X509_NAME_cmp function use RFC 5280 section 7.1 and RFC 4517
section 4.2.15 (which in turn reference RFC 4514 for the DN string format).
libnss has CERT_AsciiToName which is referencing RFCs 1485, 1779 and 2253 in
lib/certdb/alg1485.c. Comparing the two would be interesting.
> Even when using RFC 2253 (now 4514) escaping, there are things left to the implementation, such as the order of AVAs
insidemultivalued RDNs. The RFC warns not to consider these representations to be canonical forms, so it's possible
thatswitching (or upgrading) the TLS library in use could force users to change their regexes at some point in the
future.
Right, multi-value RDN's are defined as sets so C=US,A=B+C=D is equivalent to
C=US,C=D+A=B according to RFC 5280.
--
Daniel Gustafsson https://vmware.com/
