Minutes for ACME at IETF-94
minutes-94-acme-1

2015-11-06 09:01:43+0900
Chairs: Ted Hardie and Rich Salz
note-taker: dkg


Administrivia -- nothing added to the agenda.


Rbarnes discusses moving from -00 to -01


## Ayers signature reuse attack


token.fingerprint is now a standard mechanism, to avoid using
non-standard properties of


## default virtual host gets to assert validations from everyone else.


no more https for HTTP validation.


TLS SNI validation now has multiple phases


PLEASE IMPLEMENT!


dealing with issues and pull requests:


#23 -- adding domain to challenge address


 -- Ted Hardie (no hats) says that the byte limit will be a problem for
    enterprise deployments with long names.


#17 -- add ratelimited error


 -- real question is how do we manage the error namespace?


 -- Leif Johanneson: it depends on how the registry space should be
    requested.


 -- Ted Hardie (no hats) no problem with non-URN ACME namespace errors.
    But we should pull the URN out to a separate document and try to
    get it processed separately, because that registration process is
    slow.


 -- chairs will find someone to drive this urn in the right direction.


 -- Leif: we should have specification-required iana registry for
    errors in the urn:acme namespace, and let other people use
    whatever uri's they want.


 -- Melinda Shore: semantics and logistics of registering urn:acme
    should be fine.


 -- Martin Thomson: why not reuse one of the existing URNs that we
    have already registered.


 -- Ted (no hats): i still think it should be a separate document


 -- Martin: we're discussing things that relate to the problem draft.
    rather than prescribe what goes in that field here, we can leave
    that up to that draft.  we don't need more than that.  Servers can
    always return 503 with no error message; so clients need to deal
    with an unknown case anyway.


 -- Richard: if we get a URN space, we should make errors a subset of it.


 -- Martin: RFC 3553: an IETF URN subnamespace for registered protocol
    parameters.


#9. Use an extension for simplehttp (http-01) paths


  * how do we deal with content-type issues?


 -- Barnes proposes ignoring content-type.


 -- Ted: text/plain gives you the chance to decorate with charset.
    Are we specifying that the content has a specific encoding?  what
    if the encoding is different?


 -- Barnes: default encoding for text/plain?


 -- dkg: iso-8859-1.


 -- Ted: so a server with a default content-type and charset is
    incomaptible with iso8859-1 could have trouble.


 -- Martin: we should specify that a particular encoding is used.
    we're using base64, then produce an ascii string.  server can do
    minimal normalization (e.g. line endings)


 -- Ted (no hats): validation is likely to fail with other characters.
    I disagree with martin, and you should disallow whitespace.


 -- dkg: server admins will be confused by "xyz" doesn't match "xyz
 " -- their editor might always introduce trailing newlines.


 -- Ted: maybe do prefix matching?  permit whitespace only at the end
    of the string.


 -- Martin: sure, that's OK.  just allow whitespace at the end.  or
    even just "carriage return" and "line feed"


 -- dkg: fine, please allow all whitespace at the end.


#14. Support key rollover for account key


 -- how does a client roll over their account key?


 -- Ted (no hats): What if the client would just create a new account
    with authorizations for the same domains?  then you just need an
    account destruction operation


    Nice thing about this is that account recovery process is the same
    as account key rollover.


 -- Jason Jones: (lets encrypt) in practice, we have special
    relationships with certain providers.


 -- Ted: you're OK with having credential loss mechanism for people
    with no special relationships?


 -- Jason: I'd like to be able to track one organization beyond just a
    public key which changes.


 -- Richard: we do have recovery mechanisms in the draft, which are
    very heavyweight.  So we have two mechanisms; it seems plausible
    that we have a third, which is an orderly way to do it.


 -- Robin Wilton: Please think about these from ACID transaction
    properties.  I've been stuck in mid-transaction process before
    with other services.


 -- Richard: i'd like to hear more thoughts on this.


Richard presents the proposed structure.




#25. exposing endpoint for CT SCT proofs.


 -- Linus Nordberg: an SCT is only a promise of future inclusion.
    Would it be possible to get a full inclusion proof?


 -- Richard: inclusion proofs change over time, because they're
    relative to an STH, which changes over time.


 -- Linus: privacy issues aren't relevant, since you *are* the cert.


 -- Richard: is there a format?


 -- Linus: yes, there is an HTTP point for that.


 -- Richard: i'm still inclined to lean toward SCTs because that's
    what people are using today.


 -- Russ Housley: remember you've got multiple logs, so you need more
    than one of these.


 -- dkg: you could have different types of link, one for SCT, one for
    inclusion proof.


 -- Richard: yes, we can do that with all logs, since multiple Link
    headers are allowed.


 -- Martin: please don't block this on any theoretical C work.


#16. HTTP-01 protocol


Leading zero-octets in MPIs are trouble.


 -- Barnes: we should require stripped leading zero-octets, a la JWK


#16. Request Certificate Lifetime


 -- CSRs don't have validity


 -- stuff the duration in the json surrounding the CSR


 -- Rich Salz (no hats): what if the server can't agree to the
    client's request?  should it fail?  or adjust?


 -- Richard: up to the CA.  can you file an issue about it?


 -- Melinda: ISO-8601 has a duration format


 -- Robin Wilton: durations (like months) are culturally specific.


 -- Martin: please don't use ISO-8601 duration, it's a nightmare.


 -- Melinda: i don't like durations, i think they're confusing, i was
    just saying them for completeness.


 -- Russ: your example has both, what do you do if they don't match?
    Please don't make the request able to include inconsistent
    requests.


 -- Speakers: clients have date skew


 -- Ted Hardie: this is a perfect illustration of why we shouldn't do
    durations.


 -- Mike Jenkins: caveat:  CAs need
    to verify the dates and not blindly sign them.


 -- Max Para: another option: we could include a "this date forward"
    and then a duration?  This makes it possible for clients to do
    pre-issuance and to align their request with CA issuance policy


 -- Richard: do we need notBefore?


 -- Deb Cooley: if you do have clock skew, notBefore allows clients to
    tell you that.


 -- Rich: forward issuance is useful for operations.


 -- Richard: fine, we keep notBefore.


 -- Deb: is the request signed?


 -- Richard: yes, it is signed, every request is signed.


#22. Simplify TLS SNI challenge


proposal: don't require multiple checks?


 -- Ted Hardie (no hats): doesn't this allow the hosting provider to do
    stuff that doesn't get logged?


 -- Richard: hosts can compromise you anyway.


 -- Ted (no hats): so the concern is that these multiple checks are
    too complex for a legit user?  It makes me nervous to remove it.
    Are there texts or additional checks CAs can make?


 -- Richard: maybe we can write some text to give guidance for CAs to
    check whether the "default vhost" is in place?


 -- Rich: this might be operational and not protocol.


#4: ports other than 443?


 -- can we do other ports?


 -- this is a double-edged sword.


 -- dkg: i want an srv-name validation


 -- richard: ok, that's a different issue: should we do this for dnsname sANs?


 -- Martin: please don't close the ticket here, we get hundreds of
    mails about this.


 -- Ted: what about text that explains why we think dnsNames are
    sketchy; have a system in place to do srvNames; tell people who
    want certs on alternate names to get those certs.


 -- Martin: we need a pull request on github where people are begging
    for this.


 -- Ted: i'm not happy about having the conversation only on github.


 -- Martin: pull request, but link it to the mailing list.


 -- Ted: as long as it links back to the mailing list, that's ok.
    does the rest of the room have any way forward?


 -- Jeff Hodges: we should think about how this plays into RFC 6125.
    If we add something to that spec, we should make sure that gets
    updated properly.  I'm willing to review.
 (Note:  there are two Jeff Hodges in the WG; the above is the Fido Alliance Jeff)

 -- Max: we're discussing a very small example of the things that
    are not on the port 443 use case.


 -- Richard: we have a specification for a generic validation
    mechanism (srv), and if people really want something that matches
    the dnsName for some other service, we ask the to define a
    validation mechanism (e.g. for imaps)


--------------


Account recovery: we have a token-based account recovery mechanism.
It seems like too much to me.


 -- Phil Hallam-Baker (from XMPP): get rid of it.


-------------------


Ted Hardie: IETF-95 is 5 months away.  Mailing list action is sparse.
please review and interact before the meeting.  Please IMPLEMENT!
Share your experience early and often with this spec.


Richard Barnes: folks who have experience with existing issuance APIs,
i want to know how ACME maps to your APIs.  If it's not clean, let us
know what we need to do to align it.


Jason Jones: if you're building a client, let's encrypt runs a staging
network, please connect to it.