Subject: CRLNumber definition and MAX

From: Peter Sylvester <[email-masked]>
Date: Tue, 09 Jun 2009 13:19:54 +0200

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

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 9 Jun 2009 08:26:03 -0400

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Sylvester
Sent: Tuesday, June 09, 2009 7:20 AM
To: pkix
Subject: CRLNumber definition and MAX

Hi,

Peter Sylvester

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 09 Jun 2009 16:24:47 +0200

> certificates have 16 octet serial number values (0..2^^127-1).

Thanks for the answer. To be sure I was not asking to
restrict serialNumbers or CRlNumbers. in fact, the definition
of CRLNumber is ok. It requires positive values and no limit
for the maximum value (in the syntax).

---

From: Michael StJohns <[email-masked]>
Date: Tue, 09 Jun 2009 11:05:00 -0400

Peter - 

I think you're confusing the ASN1 definition of "long integers" with the C language definition of a long int.

4.1.2.2 constrains the serial number INTEGER (CertificateSerialNumber) into the range [0..2^159] - NOT [0..2^31].

Mike

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 09 Jun 2009 16:35:19 +0200

I hit the send button too early.

Thanks for the answer. To be sure I was not asking to
restrict serialNumbers or CRlNumbers. in fact, the definition
of CRLNumber is ok. I massed up with the definition of MAX.
It requires positive values and no limit for the maximum
value (in the syntax). Sorry for the diversion.

The definitions of pathLen in the basicConstraints
extension indicates INTEGER (0..MAX) i.e. no maximum.
It seems that many implementations do not treat this correctly.
e.g. for the two hex values 01FF00FF00 or FF00000000

The second is not ok, but some implementations indicate 0
(the last 4 octets), the first is ridiculously high but correct
and some implementations indicate failure as a negative number.
Others indicate invalid values in both cases.

Peter

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 11 Jun 2009 11:40:28 +0200

Michael StJohns wrote:
> 4.1.2.2 constrains the serial number INTEGER
> (CertificateSerialNumber) into the range [0..2^159] - NOT [0..2^31].

Peter is not confusing the two, it's *implementations* that did it by 
allowing themselves to store a pathLen value inside a C language integer.

This being said, it's a reasonable assumption for applications to think 
it makes no sense to allow a path length to go over 2^31 and to not even 
try to handle values larger than that in pathLen, BaseDistance or SkipCerts.

I'd go so far as adding text to say something like application MUST 
handle a path length up to 20, CA MUST NOT generate a path length longer 
than 20, and MUST NOT insert a value larger than that in any of those 
three values. CRLNumber and CRLNumber would, of course, still be allowed 
to up to 20 octets in length.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 11 Jun 2009 12:15:50 +0200

> to up to 20 octets in length.

To be sure: you are saying "20", not "20 octets"? I would agree with 20 or 4711.

A path length of an "long" with 2**31-1 seems more than sufficient to me.
Putting a pathlen=20 or more is in practice the same as leaving out the field.

How long does it take to validate such a path, not even talking about
storing several tera octets of certificates. :-)

/P

---

From: Michael StJohns <[email-masked]>
Date: Thu, 11 Jun 2009 18:21:28 -0400

I responded to his first email which seemed to be talking about the serialNumber field - he's since clarified he's talking about path length

Basically, you should probably just look at the integer and if its bigger than fits in a local 32 bit INT treat it as if its an unlimited length path value.  if the issuer is confused enough to issue something ridiculous you shouldn't worry about treating it in a ridiculous manner.

I'm not sure it needs any additional text here as any value > about 20 is effectively infinite... :-) 

Mike

At 05:40 AM 6/11/2009, Jean-Marc Desperrier wrote:
>Peter is not confusing the two, it's *implementations* that did it by allowing themselves to store a pathLen value inside a C language integer.
>
>This being said, it's a reasonable assumption for applications to think it makes no sense to allow a path length to go over 2^31 and to not even try to handle values larger than that in pathLen, BaseDistance or SkipCerts.
>
>I'd go so far as adding text to say something like application MUST handle a path length up to 20, CA MUST NOT generate a path length longer than 20, and MUST NOT insert a value larger than that in any of those three values. CRLNumber and CRLNumber would, of course, still be allowed to up to 20 octets in length.