Re: Why is the crlNumber an OCTET STRING?

“monotonically increasing” doesn’t mean increase by 1. It means increase in 1 direction. So nano-seconds-since-1970 is valid, even if you only sign a CRL once a day – and doesn’t require state.

From: Peter Gutmann <[email protected]>
Date: Wednesday, 21 April 2021 at 12:50 pm
To: Manger, James <[email protected]>, Russ Housley <[email protected]>
Cc: IETF PKIX <[email protected]>
Subject: Re: [pkix] Why is the crlNumber an OCTET STRING?
[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

Manger, James <[email protected]> writes:

>Presumably CRLNumber has the “20 octet” language merely for consistency with
>CertificateSerialNumber. They sound so similar: numbering CRLs vs numbering
>certs.

Ah, that would make sense.

Just for fun, I thought about what it would take to blow past the limits of a
generic integer value, say 64 bits.  It's not just a case of running a counter
up to whatever number it is that a twenty-byte value is called, you need to
sign and publish a CRL for each one.  Let's say, rather optimistically, that
you can do a hundred a second (since it's not just raw sigs but actually
assembling and publishing a CRL), so you're doing ~10M a day.  That's about 5
billion years of issuing CRLs as fast as you can to exceed what an integer
value can hold.

Looked at another way, if you've got some way you can run something that
requires 2^160 operations you'll be doing other things, probably related to
BTC, with it instead of mucking around with PKI.

Peter.

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix