> On 20 Jan 2021, at 20:07, Jacob Champion <pchamp...@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 inside multivalued RDNs. The RFC > warns not to consider these representations to be canonical forms, so it's > possible that switching (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/
