Re: CRLNumber definition and MAX

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

I hit the send button too early.

Kemp, David P. wrote:
> 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).

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