Re: rfc 3280

["David A. Cooper" <david.cooper@nist.gov>]

Roger,

My responses are in-line.

Dave

Roger Schlafly wrote:

> I have a couple of questions about complying with RFC 3280.
>
> RFC 3280 says:
> CAs MUST force the serialNumber to be a non-negative integer ...
> Non-conforming CAs may issue certificates with serial numbers
> that are negative, or zero.  Certificate users SHOULD be prepared to
> gracefully handle such certificates.
>
> PKITS interprets this as saying that a CRL can
> revoke a cert with a serial number of -1. Why?
> It seems to me that it would be graceful to
> simply reject any cert or CRL with a negative
> serial number, since no such cert or CRL could
> be correct anyway.
>
> What does "gracefully" mean?

RFC 3280 mandates that serial numbers be positive integers that are at 
most 20 octets long, but X.509 simply states that serial numbers are 
integers.  So, a certificate with a negative serial number is not 
incorrect, it simply was not generated in a PKIX compliant manner.

It is true that RFC 3280's requirement to gracefully handle certificates 
with negative serial numbers is vague.  It would probably be considered 
PKIX-compliant to simply reject any certificate with a negative serial 
number or any CRL with a negative serial number in its list.  PKITS has 
two tests that involve negative serial numbers.  In test 4.4.15, the 
outcome should be the same no matter what.  The end certificate has a 
negative serial number and the end certificate is listed as revoked.  
So, every client should consider the certification path to be invalid.  
In test 4.4.14, the end certificate has a positive serial number, but 
the corresponding CRL includes a negative serial number in its list of 
revoked certificates.  If one rejected CRLs that listed negative serial 
numbers, then this path would be rejected (since it would not be 
possible to determine the revocation status of the end certificate) even 
though PKITS indicates that it is valid.

While RFC 3280 is rather vague about its requirements for processing 
certificates and CRLs that include negative serial numbers, NIST 
believes that relying parties should be able to process them since they 
may appear in valid X.509 certificates.

> RFC 3280 also says:
> the sign bit in the DER encoding of the INTEGER value MUST be
> zero - this can be done by adding a leading (leftmost) `00'H octet if 
> necessary.
> ... serial numbers can be expected to
> contain long integers.  Certificate users MUST be able to handle
> serialNumber values up to 20 octets in length.  Conformant CAs MUST
> NOT use serialNumber values longer than 20 octets.
>
> Is the 20 byte limit calculated before or after
> adding the 00 byte? (This matters because some CAs
> use a 20 byte SHA1 value instead of a serial number,
> and that value may need a pad byte.) 

I do not see any problem using a SHA-1 value as a serial number.  In 
theory, there could be a hash collision that would result in a CA 
issuing two certificates with the same serial number, but I would guess 
that the odds of this happening are so small that it is not worth 
worrying about.

On the other hand, I interpret RFC 3280 to require that the entire 
encoding of the serial number fit within 20 octets.  So, if one used a 
SHA-1 hash to generate serial numbers, any hash values whose most 
significant bit was set would require a padding byte to make the 
resulting value a positive integer, leading to a 21 octet serial number 
that does not conform to the requirements of RFC 3280.

Since there is no explanation in the document, I do not know where the 
20 octet limit came from, but it is possible to the authors anticipated 
people using hash values to generate serial numbers.  Perhaps the 
authors did not consider that the output of the hash might have the most 
significant bit set thus requiring the addition of a padding byte in 
order to ensure that the resulting number is positive.

Since this is an issue related to RFC 3280 and not PKITS, I would 
suggest bringing up the issue on the PKIX mail list.  If there is an 
agreement that it is acceptable to generate serial numbers as you 
describe above, then perhaps the successor to RFC 3280 could state that 
serial numbers must be at most 21 octets long.

Dave