RE: CRLNumber definition and MAX

["Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>]

I'm not sure I understand the rationale for removing the constraint on
serial numbers - why would you want to encourage (or at least permit)
negative serial numbers?  The explanation for a SIZE(1..MAX) constraint
on SET/SEQUENCE is helpful but is not particularly relevant to range
constraints on INTEGER values.

Does anyone see a problem with continuing to restrict CRLNumber (and
CertificateSerialNumber) to being non-negative?

I believe there would be a problem with restricting serial number range
to 0..2^^31-1, since (if I recall correctly) some currently-issued
certificates have 16 octet serial number values (0..2^^127-1).

Dave


-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Peter Sylvester
Sent: Tuesday, June 09, 2009 7:20 AM
To: pkix
Subject: CRLNumber definition and MAX


Hi,

RFC 5280 contains the following definitions for a CRLNumber

CRLNumber ::= INTEGER (0..MAX)

I think that as an analogy with CertficateSerialNumber the
constraint (0..MAX) should be removed, cf also appendix B:

   "As noted in Section 4.1.2.2, serial numbers can be expected to
    contain long integers.  Certificate users MUST be able to handle
    serialNumber values up to 20 octets in length.  Conforming CAs MUST
    NOT use serialNumber values longer than 20 octets.

    As noted in Section 5.2.3, CRL numbers can be expected to contain
    long integers.  CRL validators MUST be able to handle cRLNumber
    values up to 20 octets in length.  Conforming CRL issuers MUST NOT
    use cRLNumber values longer than 20 octets."


The ASN.1 appendix (B) also ontains

    "The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
    constructs.  A valid ASN.1 sequence will have zero or more entries.
    The SIZE (1..MAX) construct constrains the sequence to have at least
    one entry.  MAX indicates that the upper bound is unspecified.
    Implementations are free to choose an upper bound that suits their
    environment."

but nothing similar concerning INTEGER (0..MAX)

Is there someone who sees an important problem if we would require
that MAX MUST be smaller that 2**31 in order to be conformant
to the profile.

The construct occurs in 4 types, the three others being
   pathLenConstraints
   BaseDistance
   SkipCerts
I haven't checked other Extensions defined in X.509.

Peter Sylvester