Re: [Pki-devel] ACME certificate IDs

----- 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?