Re: are CN=.# and CN== valid?

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