Re: [Pki-devel] ACME certificate IDs
----- 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? Is issuer DN unique enough? How do we join with
the serial number? What format do we use for serial number? What if
we need to add another field in the future? It seems there's going to
be many questions/issues with this solution.
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. The cert ID is not meant to be human readable anyway (as
shown in RFC 8555).
--
Endi S. Dewata