Re: [Pki-devel] ACME certificate IDs
On Tue, Mar 17, 2020 at 05:04:59PM -0400, Endi Sukma Dewata wrote:
----- Original Message -----
> Hi Endi,
>
> Just want to quickly discuss certificate IDs.
>
> Currently on ACMEBackend interface we have
>
> public BigInteger issueCertificate(String csr);
>
> I think this is a bit of a problem. e.g. Dogtag currently supports
> multiple issuers (LWCAs). It is incidental that serial numbers do
> not collide. This might not hold for other backends. Yet we need
> the certificate ID to uniquely identify the certificate, so that we
> can retrieve it, revoke it, etc.
>
> I suggest changing the return value to a string (which is how it
> gets stored in the ACMEOrder object anyway).
>
> I'd further suggest that by convention, where possible, the string
> be a representation of issuer+serial, which is a bit nicer for
> humans looking at the stored objects than a base64url-encoded
> big-endian bigint.
>
> What do you think?
>
> Cheers,
> Fraser
Hi Fraser,
I agree there is a problem, but I'm not sure about using issuer+serial
as certificate ID. What do we use as "issuer", is it the issuer DN
or the authority ID?
The issuer DN.
Is issuer DN unique enough?
(issuer, serial) pair must be globally unique.
How do we join with
the serial number?
What format do we use for serial number?
Doesn't really matter as long as it is unambiguous. For example,
serial as decimal number, followed by ';', followed by string
representation of Issuer DN.
What if we need to add another field in the future? It seems
there's going to
be many questions/issues with this solution.
It is up to the ACMEBackend to produce a certificate ID. I'm simply
proposing this because a backend could contain multiple CAs with
separate serial number domains, hence deriving certificate ID from
serial number alone would not be unique. The idea of
(issuer,serial) pair is just a suggested convention. Some backends
e.g. might prefer UUIDs or whatever makes it easy to retrieve a
certificate/chain.
How about this instead?
1. Change issueCertificate() to return the full cert chain.
2. Store the cert chain in a "certs" table in ACME database.
3. Autogenerate the cert ID for each cert record.
4. Store the account ID in the cert record.
5. Store the cert ID in the order record.
So a copy of the cert will be stored in ACME database. The cert
ID will be unique for that particular ACME server. We don't need
to include the issuer DN/ID. The cert serial number will not matter
either. We can also use the certs table to authorize revocation
requests.
I thought about this a little while back, and I prefer the current
approach of storing an identifier as a "handle" to retrieve the cert
from the backend. Cert objects will increase the size of
records/objects significantly. For the LDAP backend it could be a
problem, both for disk usage but in particular for replication.
I'm OK with the idea of *optional* certificate/chain storage in the
ACME database, e.g. for backends that do not support retrieval. But
I don't think we need that with the current backends (certainly not
with the PKIBackend).
The cert ID is not meant to be human readable anyway (as
shown in RFC 8555).
But it doesn't matter if it is human readable. Either way, storing
only the serial number is not enough IMO.
Cheers,
Fraser