On Thu, Dec 05, 2019 at 11:18:15AM +1000, Fraser Tweedale wrote: > On Wed, Dec 04, 2019 at 06:36:24PM -0500, Endi Sukma Dewata wrote: > > ----- Original Message ----- > > > Just want to flag something related to ACME orders and > > > authorisations. > > > > > > In ACME authorizations can be shared by multiple orders. In fact > > > you can also "preauthorize" your account for an identifier, so there > > > can also be a authorizations with no orders attached. > > > > > > Does the way we have implemented the ACME service ensure that an > > > authorization has only one order (or at most one order)? If so, do > > > we want it that way? It entails that every identifier must be > > > re-authorised upon every order. > > > > > > Personally I think this is not the way we want to go. Let me > > > describe a scenario. > > > > > > Client orders a cert for a.example.com, completes the authorisation > > > for a.example.com, and gets the cert. > > > > > > Shortly afterwards, they realise they also need b.example.com on the > > > certificate. So they make a new order with BOTH identifiers. > > > > > > Should the client have to complete another authorisation for > > > a.example.com, while their existing authorisation remains "fresh" > > > (unexpired)? It is valid to require the client to re-authorise > > > every identifier for every order. But it is not optimal. Ideally > > > we should observe that for the account there is already a > > > non-expired authorisation for "a.example.com", and attach that to > > > the order (along with the new authorisation for "b.example.com" > > > which the client must complete). > > > > > > Anyhow just some ideas as I proceed with implementation of the LDAP > > > database implement. Let me know your thoughts. > > > > I think you're right. The database schema itself is not limiting to > > one order per authorization, but the current code is making that > > assumption. > > > > We could change getOrderByAuthorization() to getOrdersByAuthorization(), > > then move this code into a loop to process all orders associated to > > that authorization: > > https://github.com/dogtagpki/pki/blob/master/base/acme/src/org/dogtagpki/acme/server/ACMEChallengeService.java#L124-L144 > > > > If we want to reuse existing authorizations, we will need to modify this > > code to find an existing authorization that is still valid instead of > > creating a new one: > > https://github.com/dogtagpki/pki/blob/master/base/acme/src/org/dogtagpki/acme/server/ACMENewOrderService.java#L72-L83 > > > OK, I'll file a ticket now and we can come back to it later. > Ticket is https://projects.engineering.redhat.com/browse/RHCS-814, part of the RHCS-35 epic.
Cheers, Fraser _______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel