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
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel