[cabfpub] RFC5280

[Ryan Sleevi]

On Feb 24, 2016 10:56 AM, "Jeremy Rowley" <jeremy.rowley at digicert.com>
wrote:
>
> I’ve been playing around with Peter Bowen’s certlint (an excellent tool)
and, looking at the cert universe as a whole, there are some noticeable
issues with the BRs and RFC 5280 that I though merited a public CAB Forum
discussion.  Some of this is likely me not knowing the entire history of
5280, so I appreciated any explanation. If there’s exceptions we would like
to make to RFC5280, we should probably also push a bis with IETF at the
same time.
>
>
>
> Here’s what I’m noticing are common issues:
>
> 1)      Org names, common names,  and address fields are limited to 64
characters. Very few international companies can comply with this
restriction. It’s even worse if you are converting an IDN to a printable
string.  I don’t think any browsers limit this to 64 characters?  Is there
a strong objection to permitting longer strings in these fields?

Yes. Plenty of tools rely on the schema as defined by 5280 - and as such,
ignoring it causes real compatibility issues.

> 2)      keyAgreement isn’t specifically prohibited in the BRs or 5280.
However, keyAgreement should no longer be used in ECC certs because of
security issues as explained by Ryan Sleevi in previous emails . We should
update the BRs to prohibit keyAgreement.
>
> 3)      Years ago, we discussed that 2047 bit certs were equivalent to
2048 bit certs (although the discussion may have occurred solely on the
Mozilla mailing list).  We should codify this exception.

IMO, this is a giant hack that browsers did because CAs have trouble
counting (see also: serial numbers), which itself is a statement that the
underlying libraries played a very liberal definition.

I would prefer not.

>
> 4)      Why is teletext string not permissible on a lot of these fields?
I also don’t understand the weird requirement to use printablestring over
UTRF8 for some fields. Specifically, requiring a printable string for
subject:serialNumber could cause issues with the EV Guidelines if a country
uses an IDN as part of their registration number.

TeletexString is the worst string - good luck trying to find a single
parser that properly understands it, or a single version of the spec that
is unambiguous.

It would be different if you are talking UTF-8 string, but certainly any
new appearances of TeletexString should be forbidden.

We have zero desire to support this string, and if CAs followed RFC5280,
that would not really be an issue.

Overall, your proposals 1/4 will explicitly fragment the market and the
specs - and that's something that should not be supported or encouraged. 2
is basic operational sanity, and 3 is one of those gross things that would
ideally be deprecated rather than codified.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160224/ebe5b281/attachment.html