2016-07-26 23:03 GMT+02:00 Richard Barnes <[email protected]>: > Hey folks, > > At the IETF meeting, EKR pointed out the need to have a > "pre-authorization" function in ACME, where the client can get > authorization to issue for certain names without causing a certificate to > be issued. Having thought about this a bit on the way home from the > meeting, I'd like to get some feedback on how to go about this. >
Could you line out the reason for the need? Thanks, Niklas > As a starting point, consider the following options: > > Option 1: Add a "preAuth" flag to the application request/struct, such > that if that flag is set, then the server will not issue a certificate once > the application completes. However, that would still require the client to > send a CSR, which on the one hand is a hassle (unneeded public-key > operations) and on the other hand, risks bad server implementations missing > the flag and issuing anyway. > > Option 2: copy/paste the "new-authz" flow back into the spec. However, > that's a lot of spec machinery to re-import, and it doesn't allow the CA to > express any sort of simplification due to multiple domain names, such as > the "just validate the top-level domain" policy in the other thread that's > going on right now. > > Given those trade-offs, I wonder if some sort of intermediate approach > would be better. The best thing that's come to me so far is to fork the > application process: > > - Add an "identifiers" field to the application object > - Each application MUST have exactly one of "csr" and "identifiers" > - If "csr" is present, then do what's in the draft now > - If "identifiers" is present, then do the same dance, but don't issue the > certificate > > Does that sound sane to folks? It still seems slightly gross to me, > because of the switching based on the presence of fields. Anyone have > better ideas? > > Thanks, > --Richard > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
