It looks like: CN=\#. as well. scanVal() strips off the \ leaving '#', ParseRFC1485AVA(), seeing a leading '#' then wrongly concludes it is the hex encoded BER.
On Tue, 1 Oct 2019 at 16:27, Andrew Cagney <[email protected]> wrote: > > CERT_AsciiToName() rejects both because the '=' and '#' appear > un-escaped in the RHS per SPECIAL_CHAR() macro. > > It would appear that one of the changes from > https://tools.ietf.org/html/rfc2253 to > https://tools.ietf.org/html/rfc4514#section-2.4 was to drop this as a > requirement: > > - one of the characters '"', '+', ',', ';', '<', '>', or '\' > (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, > respectively); > > It's mentioned in https://tools.ietf.org/html/rfc4514#appendix-B > > + did not require escaping of equals sign ('=' U+003D) > characters, > + did not require escaping of non-leading number sign ('#' > U+0023) characters, > > It also seems to allow other even more weird stuff involving spacing, > for instance: > CN = \ . \ , ... other stuff ... > which I think is the C string "CN=\040\\\040\040.\040\\\040\040, ...." > and with the CN set to "\040\040.\040\040". > > Andrew -- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
