[cabfpub] RFC5280

[Geoff Keating]

> On 24 Feb 2016, at 1:08 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> 
> 
> 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.)
> 
> [JR] I realize this is characters but there are definitely names longer than 64 characters out there. I guess the easy way is to get a DBA in all cases where the name is too long.

Not really, you have to have both the DBA and the real name in the certificate so this just makes it worse.  However the EV guidelines do allow you to shorten the name (with limitations).

> 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.
> 
> [JR] See Peter Bowen's email for the explanation:
> " I think there is a misunderstanding here. There has never been a requirement that the modulus contain a certain number of bits set to ‘1’.  What is required is that the modulus be a 2048-bit number.  The problem is that a 2048-bit number can have one or more of the high order bits being zero.  When calculating the modulus “size”, all an observer can do find the left-most bit set to ‘1’ and use that.  RSA moduli normally are the product of two prime numbers. OpenSSL and some other generating tools have a function that makes the top bit of each prime number to be 1 which ensures the result will have the top bit set to 1.  However a random prime could be smaller, resulting in a smaller results.”

I think this is incorrect.  A 2048-bit number is a number between 2^2047 and 2^2048-1.

-------------- 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/5d10e444/attachment-0001.p7s>