[Pki-devel] ACME certificate IDs

[Fraser Tweedale]

On Fri, Mar 20, 2020 at 03:41:05PM -0400, Endi Sukma Dewata wrote:
> ----- Original Message -----
> > > Let me backtrack a little bit. Is there a plan to modify Dogtag to
> > > eventually support different serial number domains? If not, this is
> > > not an issue for Dogtag.
> >
> > There is no plan to do so.  It is not an issue for Dogtag.  But
> > still, I feel basing certificate ID on only serial number is not a
> > robust approach in general.
> > 
> > > If there is such plan, will the issuer DN
> > > be unique across LWCAs? If issuer DN will be unique, it's something
> > > to consider. If not, (issuer DN, serial number) will not be unique
> > > either, so we need to use something else such as authority ID.
> > > 
> > > Or is there another backend with multiple issuers that we want to
> > > support in the future? The cert ID will have to be something like
> > > (issuer ID, serial number) where the issuer ID is unique for the
> > > backend. If the issuer DN is unique, it can be used as the issuer
> > > ID. Otherwise, it needs to be a backend-specific unique ID similar
> > > to authority ID in Dogtag.
> >
> > All certs must have unique (issuer,serial).  This is implied by the
> > requirement that all certs from a given issuer must have different
> > serial numbers.
> > 
> > > We need to consider these possibilities before changing the cert ID.
> > > On the other hand, I'm still not sure it's actually necessary to
> > > include these information into cert ID.
> > > 
> > > Let's look at the code. For cert enrollment (ACMEFinalizeOrderService)
> > > we convert the serial number that we get from ACMEBackend into cert ID:
> > > 
> > >   BigInteger serialNumber = backend.issueCertificate(csr);
> > >   String certID =
> > >   Base64.encodeBase64URLSafeString(serialNumber.toByteArray());
> > > 
> > > We can change it so ACMEBackend can generate the cert ID like this:
> > > 
> > >   String certID = backend.issueCertificate(csr);
> > > 
> > 
> > I strongly agree with pushing the certID generation into the
> > ACMEBackend.  Stepping away from the whole (issuer,serial)
> > discussion, say (for example) the only "handle" a backend has for
> > accessing a cert is a UUID.  Then storing the serial number is no
> > good - you cannot derive the UUID handle from the serial number.
> > 
> > So the backend must generate the (String) certID that is appropriate
> > for that backend.
> > 
> > > If the cert ID is (issuer DN, serial number), we can generate the
> > > cert ID from the new cert. But does the backend return the new cert
> > > or just the serial number?
> > >
> > Yeah, good question; of course you must be able to retrieve the
> > cert (and therefore you can learn the Issuer DN) but this could mean
> > another round-trip to Dogtag.  Which is the next thing you said :)
> > 
> > > If the serial number is not unique, the
> > > backend might need to be changed to return the cert itself so we
> > > can get the issuer DN.
> > > 
> > > If the cert ID is (authority ID, serial number), how do we get the
> > > authority ID since it's not included in the cert? The backend might
> > > need to be changed to return the authority ID along with the new
> > > cert, or to provide a way to look up the authority ID using a cert.
> > >
> > I am not suggesting to use the authority ID.  But FWIW Dogtag does
> > enforce that Issuer DN <-> Authority ID is a bijection.
> > 
> > > 
> > > For cert retrieval (ACMECertificateService) we're passing the cert ID
> > > to ACMEBackend:
> > > 
> > >   String certChain = backend.getCertificateChain(certID);
> > > 
> > > The ACMEBackend can extract the issuer DN or authority ID from the
> > > cert ID so it can retrieve the cert from the backend again.
> > > 
> > > Since we get the cert during enrollment anyway, we can actually store
> > > it into ACME database like this:
> > > 
> > >   String certChain = backend.issueCertificate(csr);
> > >   String certID = database.addCert(certChain, orderID, accountID,
> > >   expirationTime);
> > > 
> > > Later we can simply retrieve it from the database instead of calling
> > > the backend again:
> > > 
> > >   String certChain = database.getCertificateChain(certID);
> > > 
> > As I said in previous email, I am opposed to storing the cert
> > (chain) in the ACME database.  If some backend requires it e.g.
> > because the backend itself does not store the cert, then it can be
> > optional.  But we do not need that now.
> > 
> > > Here the cert ID can simply be a unique ID generated by the database.
> > > Unlike earlier, the backend doesn't need to know about cert ID at all.
> > > 
> > > For cert revocation (ACMERevokeCertificateService) the client will
> > > only provide the cert binaries. It doesn't provide the cert ID.
> > > 
> > And the ACMEBackend implementation receives the cert, and must work
> > out what to do with it.  How it tells the backend system to revoke
> > the certificate, and whether that process even involves a string
> > CertID handle, or just a serial number, or the (issuer,serial) pair,
> > or whatever, depends on the backend system.  But I think that the
> > current interface:
> > 
> >     public void revokeCert(ACMERevocation revocation) ...
> > 
> > ... is suitable.
> > 
> > > Currently the ACMEEngine.validateRevocation() will generate the
> > > cert ID from the serial number so it can find the order that
> > > generated the cert (so we can authorize the account):
> > > 
> > >   String certID =
> > >   Base64.encodeBase64URLSafeString(serialNumber.toByteArray());
> > >   ACMEOrder order = database.getOrderByCertificate(certID);
> > > 
> > > We can changed it so ACMEBackend can generate the cert ID like this:
> > > 
> > >   String certID = backend.getCertID(certBytes);
> > >   ACMEOrder order = database.getOrderByCertificate(certID);
> > > 
> > > If the cert ID is (issuer DN, serial number), we can generate the
> > > cert ID from the provided cert binaries. But if the cert ID is
> > > (authority ID, serial number), how do we get the authority ID? Do
> > > we call the lookup operation above again to get the authority ID?
> > > 
> > > Instead of that we can do this:
> > > 
> > >   String certID = database.getCertID(certBytes);
> > >   ACMEOrder order = database.getOrderByCertificate(certID);
> > > 
> > > which doesn't involve the backend at all.
> > > 
> > > So backend-issued cert ID might work if we use a backend that
> > > already provides the required functionality above. Otherwise we
> > > may need to modify the backend, which is not always an option.
> > > 
> > > The database-issued cert ID is a solution that doesn't require
> > > modifications to the backend, so I think it should be the default
> > > option. The certs stored in ACME database should be considered
> > > a cache. The server can purge it so it doesn't grow too large if
> > > that's a concern.
> > > 
> > > Note that regardless of cert ID, the above revocation mechanism
> > > relies on order, authorization, or cert records in ACME database,
> > > which may not be available depending on the server's purging
> > > policy. If someone needs to have a reliable revocation mechanism
> > > they need to revoke using the private key.
> > > 
> > Let us put aside the discussion about whether for the PKIBackend we
> > use only (serial) as certID, or (issuer,serial) pair.  I think we
> > *should* switch to something derived from (issuer,serial), but we do
> > not *need* to.  So we can leave that discussion for now.
> > 
> > The main change we need is for ACMEBackend.issuerCertificate to
> > return String certID, i.e.:
> > 
> >     public String issuerCertificate(String csr) ...
> > 
> > because BigInteger (i.e. serial) may not be an appropriate "handle"
> > for all backends.  Hence we should require each ACMEBackend
> > implementation to produce the appropriate certIDs.
> > 
> > Do you agree?
> > 
> > Cheers,
> > Fraser
> > 
> 
> Hi Fraser,
> 
> Please take a look at this PR:
> https://github.com/dogtagpki/pki/pull/350
> 
> So the PKIBackend will continue to work like before, but
> these changes should allow us to support:
> - both single-authority and multi-authority backends
> - both one-step and two-step enrollments
> 
> One thing though, I think we discussed before about using UUID to
> generate the serial number which has a very low chance of collision.
> If a backend uses UUID for all of its certificate authorities, can
> the serial number by itself be considered unique?
> 
Practically speaking, I'd say yes.

As I already discussed at length, I'd prefer we rely on what X.509
*requires* to be unique (i.e. (issuer,serial)) where possible.  But
if we are confident a backend with multiple issuers has a single
serial number domain (whether they are UUIDs or just a single
sequential source like Dogtag), *and* that this property is unlikely
to change, then I can live with it.

I'll try to review PR 350 today.

Cheers,
Fraser