[cabfpub] RFC5280

[Geoff Keating]

> On 24 Feb 2016, at 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?
> 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. 
> 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.  
>  
> Thoughts?
>  

I think these are generally controversial.

I draw to your attention that it really is 64 characters, not 64 bytes.  If you use utf8String, bmpString, or universalString it can be much longer than 64 bytes when encoded in DER.  (X.690, 51.5.4, “The count of the number of characters … shall be clearly distinguished from a count of octets.”)  So I’m not sure what the IDN problem is.  The standard does allow for abbreviations.  This also seems to me like something that should be argued in the PKIX working group or the ITU, not the CABforum.  (The original spec for this value is ITU X.411, I think, but not for all the limits, which explains why the limits are inconsistently 64 or 128.)

keyAgreement is fine, the problem is with TLS, and with using the same key for both agreement and signature.  I support updating the BRs to say that certificates must have one or the other not both.

It is not clear to me in what way 2047 == 2048 and why the same logic can’t be applied repeatedly to say that 1024 == 2048.

TeletexString is an abomination, and deprecated by the ITU, and not allowed by PKIX except for backwards compatibility, and it is not implemented completely in any implementation that I know of.

For serial numbers, is there actually a jurisdiction that does this?  It seems unlikely, most of the places which might want to do it need serial numbers to identify companies with something which can be represented in ASCII.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3321 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160224/b05051c3/attachment-0001.p7s>