Minutes for ACME at IETF-96
minutes-96-acme-2

#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!"