Minutes for ACME at IETF-96
Automated Certificate Management Environment
||Minutes for ACME at IETF-96
* IETF-96 ACME working group
* Chairs: Ted Hardie, Rich Salz
* Minutes: Joe Hall
* 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
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
RLB: we are doing a string compare, one is from the ACME JWS, what is the
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
might want to say, "perform some simple transformations", should work. (if
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
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.
instead of sending CSR last, send it first
CA can response with requirements upon receiving CSR that specify auth
in the new flow, you send not a request for a cert, but an "application"
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
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
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
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
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.
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
RLB: unless any objection, going to drop "Challenge"
DECISION: drop Challenge; if we need OOB Challenge, we can add it back
want to change account key from oldKey to newKey
Need a multi-signature JWS, which some don't support.
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.
LE folks suggested only require nonces in POST responses, plus some sort of
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
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.
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
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
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,
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!"