#ACME * IETF-96 ACME working group * Chairs: Ted Hardie, Rich Salz * Minutes: Joe Hall Agenda: * 15:40-15:50 Administrivia: agenda bashing, note well, etc. * 15:50-17:00 ACME issue review and prep for WGLC * 17:00-17:40 What's next -- WG post-IESG review Summary of decisions: * support both old and new 'applications' flow * Add version into protected payload * For issue 157, decided to return 302 * drop Challenge; if we need OOB Challenge, we can add it back later. * verify sig_new(M,sig_old(M)) for key rotation on the list. * For 156, keep nonces Summary of actions: * Russ to draft a paragraph or couple sentences on replacement key operational considerations * Request to the mailing list "hey, if you have a post-v1-WGLC, tell us or this may not exist further!" Detailed notes follow. ## review of changes in -03 Security improvements in Issues #154, #150, #147 https://github.com/ietf-wg-acme/acme/pull/154 https://github.com/ietf-wg-acme/acme/pull/150 https://github.com/ietf-wg-acme/acme/pull/147 text mostly punts, can we do better? Ted from floor mic: we should do string matching, rather than more complex types of URL comparison (e.g., percent encoding). If there is not an exact match, fail. RLB: we are doing a string compare, one is from the ACME JWS, what is the other, Ted? Martin Thompson: RFC 7230 section on URI normalization... makes recs about what to do about % encoding. Doesn't get close to rec'ing an interoperable canonical format. might want to say, "perform some simple transformations", should work. (if not, debug) would recommend that clients use absolute form... know that we can't do that because "stuff gets lost in translation" Ted, clarifying: because the server generates the URL that is used by the client to generate the request, client should use that exactly. If composition is required due to HOST header, make minimal changes so that string match works. "round-trip the bytes the server sent you. if you do anything else, lord help you." Applications Goals not satisfied with the name (also called preconditions) make the issuance process a bit more flexible. want to support a bit more variety in CA issuance flows. Approach instead of sending CSR last, send it first CA can response with requirements upon receiving CSR that specify auth and/or out-of-band in the new flow, you send not a request for a cert, but an "application" for cert(s). EKR: say I have a system that separates orgin servers (getting certs) and auth system (approving them). in the current design, I need to make a "dummy CSR". RLB: can't obtain authorization without also obtaining a certificate. EKR: this is lame... can't have a separated system without having a "dummy CSR" that I don't actually want authorized. MT: is auth specific to "application"? RLB: you could have a flag that says, "don't actually sign this" EKR: it's silly to design a system with annoying conditions on the customer. RLB: there was feeback on the list if we are going to do this ("application" design) we get rid of new authorization messages EKR: what if I wish to issue edd25519 in the terminal identity? Now, what if my box that does registration had never heard of ed25519 and is using some other crap? Ted: if the new applications flow is modified so that the new flow is a possibility but the old authorizations would work. EKR: that would be fine. DECISION: support both old and new 'applications' flow RLB: would require those old authorizations to have no scope. Client work is similar than to before. ## A few open questions Issue 218: https://github.com/ietf-wg-acme/acme/issues/128 no in-band signaling of the version the server thinks it's speaking RLB: any preferences on stating versions? PHB: want the version to be in-band as that's the only way it can be auth'd. RLB: inside the auth'd envelope? PHB: yeah MT: what worries me here, if we make changes to the protocol that have subtle implications for fields that are under protection... things signed in one context may have problems with things signed in others. Should be very simple "This is ACME!!!" RLB: do we need both server and client versions? MT: sure RLB: ok, sounds like client to server, have a new thing that is JWS protected. DECISION: Add version into protected payload DKG: when we have a new version, all the old clients will fail explicitly, so we can't not think about that MT: we can decide to not change the version number and add stuff, but then we have to think about it Issue 157 https://github.com/ietf-wg-acme/acme/issues/157 if a client attempts to re-register with the same key, return 409 Conflict. MT: 302 found is more semantically correct. RLB: this might be hard for clients where the HTTP layer transparently handles redirects. MT: returning a 201 when create a new resource? 302 will have the location information, so no biggie. RLB: but some HTTP handles 300 series differently than 200. XHR may. DECISION: For issue 157, decided to return 302 MT: it is possible to supress redirects in Fetch. Issue 152 https://github.com/ietf-wg-acme/acme/issues/152 Drop or remove OOB challenge? For: why have two OOBs? Why keep them both? Against: what if a CA has migrated one part of it's infra to one place but not another? RLB: unless any objection, going to drop "Challenge" DECISION: drop Challenge; if we need OOB Challenge, we can add it back later. Issue 156 https://github.com/ietf-wg-acme/acme/issues/156 want to change account key from oldKey to newKey Need a multi-signature JWS, which some don't support. Propoal: sig_new(sig_old(M)) EKR: not clear to me that sig_new is a signature on M RLB: should read: sig_new(M,sig_old(M)) these are JWS objects for each sig_* Ted: having a moment. shouldn't it be sig (something) RLB: M includes the old key. Ted: send the struct to the list please PHB: there is going to be only one copy of the block that is signed? RLB: you will have a JWS whos payload is the message, signing key for that is oldKey. Serialized, base64-encoded, that's the payload for the next sig. Brian Campbell (BC): it's almost trivial to support multiple signatures even with libraries that only do a single signature ... don't think the library support for multiple signatures will be hard to do as long as the JWS unprotected headers arn't used. RLB: sig_new(M,sig_old(M)) but will take to the list with the JWS struct DECISION: verify sig_new(M,sig_old(M)) for key rotation on the list. Issue 156: Nonces LE folks suggested only require nonces in POST responses, plus some sort of priming source. proposal: drop the issue and leave the requirement as it is. MT: can we send the same nonces on each server send and not check them and this would all still work? RLB: dininclined to drop nonces and thus not remove replay protection. DECISION: For 156, keep nonces EKR: nonces are not a big deal for servers. Issues that are not yet in github issues SSLMate API requires another request to actually issue the request. "Yes, I want this cert, go ahead and issue." Should we have this confirmation from the client? AGWA (andrew ayer) said we should not do it given his operational experience. Ted: Do we undersand what we lose if we don't do this? AGWA from mic: The reason why SSLMate needs the extra step is because our API doesn't have challenges. ACME does, so it's redundant. RLB: we'll not do that, consider it closed. Recovery proposal: declare recovery truely dead. Does anyone think losing the account key is a big deal? EKR: we know from experience that this happens. RLB: but it's not such a big deal, just reissue. EKR: losing keys and someone taking over accounts is too similar for me to be comfortable with this. RLB: maybe that's out of scope for the protocol. EKR: guidance would be a good idea. CAs should have some manual process for dealing with account key recovery; we recommend they flip the account rather than continue to use the key. Russ: CA still remembers the public key, client can't access or lost the private key. A section on operational considerations that says "need to be able to create a replacement key" ACTION: Russ to draft a paragraph or couple sentences on replacement key operational considerations Russ will draft text on this. flexibility of scoping authorizations do we need more flexibility as the current scoping is very rudimentary. ## What do we need to get done before WGLC? WGLC is next Need to be comfortable that all the major issues are addressed. Are we there yet? What else? Like to have more implementations. How is the current timeline? (October for WGLC) # Close down or recharter once ACME v1 is done? RLB: for use cases we might do: ACME for EV DNS-based constraints on CAs or validation methods MT: right plan is to use this time to solicit rough drafts on extensions to v1. Kathleen: having some drafts is good before we change a charter PHB: there are non-TLS stuff that I'd like to do... DNSSEC, S/MIME, ver different auth challenges. S/MIME want to send messages over SMTP... clients can't get certs easily. Ted: q to AD: should we do this in LAMPS or stay here in ACME? Kathleen: depends on whether a WG exists or whether or not it can do the work. LAMPS would be a great place for S/MIME. DANE perhaps could be for DNSSEC. We'll have to take this on a case-by-case. eburger from mic: can't we do this AD-sponsored? Kathleen: not necessarily, need drafts. MM: yes, we were waiting for v1 to do other cool stuff. resolution of red grean will be light brown mud color. ACTION: Request to the mailing list "hey, if you have a post-v1-WGLC, tell us or this may not exist further!"