ACME Working Group meeting at IETF 100 ====================================== Thursday, November 16 at 15:50 local time (7:50 UTC) Status update ------------- Who: chairs Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-acme-chair-slides/ - Published acme-08; - OPS and Gen-ART reviews; - New versions for all new drafts. Email ----- Who: Alexey Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-acme-extensions-to-acme-for-email/ I-Ds: https://tools.ietf.org/html/draft-ietf-acme-email-tls-02, https://tools.ietf.org/html/draft-ietf-acme-email-smime-01 ### draft-ietf-acme-email-tls-02 TLS certificates for email services. See slides (#2) for a summary of the changes since Prague. Open issues: - Include port and service (e.g., smtp, imaps) in challange hash? MT: Port under the hash: OK. Are you suggesting or even requiring that the ACME server insists on a particular port number for these protocols? AM: in theory you could put any of these on a non standard port. I should probably say: CA may enforce that port number correlates to the service. MT: Ability to run TCP server on my machine on port 5000 is not a good indication that person controls the machine. Definitely want to have some text around this and maybe strongly recommend there be some policy at the CA that says: if the port number is different from what I say here then not a good idea to accept this. We did the same thing for HTTP. RB: The analogy MT was pointing at is the HTTP challenge: the CA will only connect to the validation server on port 80, which is supposedly privileged. Use the standard port for the services we are talking about. AM: OK. - Cover both TLS and non TLS ports (start plain, try STARTTLS and upgrade to TLS if available, e.g.: IMAP)? In theory same certificate could be used for both ports, in practice services and ports are different. Therefore difficult to get a certificate that covers both in one go. RB: Does not seem like an ACME issue: if certificate you are issuing is agnostic as to port number it should be fine. Only if using an SRV name or specifying the port number in the certificate then you need some binding. AM: Yes, I was thinking whether it is possible to get SAN and SRV name in the same certificate in one go. The answer is probably no. It is an optimisation, I don't think it matters in practice. JL: IMAP server I am using I don't think it has provision for doing separate certficates for the two services, so combining is important. JL: Unrelated question: any reason why POP is missing? AM: No particular reason. JL: Tiny data point: I use it. Anything that applies to IMAP equally applies for POP. AM: It'd need new capability challenge. Only DNS challenge would work out of the box. JL: Adding cap challenge should be same effort as adding it to IMAP. AM: OK will do. - Support LMTP? AM: A variant of SMTP for final delivery, some of these services are public facing. Trouble is LMTP doesn't have registered port number, and neither is the lmtp name registered. Could do registration in a separate document, no problem. Next steps: - More reviews (Richard should review); - Call for implementers, could be something in London on top of letsencrypt for example. ### draft-ietf-acme-email-smime-01 Certificates for S/MIME users. AM: Still rather raw. Done some changes but really need to flesh out how the messages are going to look like. See slides (#5) for a summary of the changes since Prague. RB: one thing not clear from the document is whether you are trying to verify someone is able to receive mail at the claimed address, or send email from that address, or both? AM: open question, but I suspect the answer is both (and sending is more powerful assertion than receiving.) JL: just being able to receive is not sufficient: I could probably get an ACME certificate for every IETF mailing list... sending is problematic as well. Probably need text in security considerations saying that a "certain amount" of spoofing of identities is unavoidable. AM: right. HN: Same point as JL. For receiving OK. For sending we need to make sure an email validation system like DMARC is mentioned in the document. AM: OK, sounds good. RB: I should observe that verification of receipt is used in typical web based workflows where email is sent to an address with a web link to click on for verification. I don't know if it's evidence of sufficiency but it's evidence that this works in some other cases. JL: (not intelligible) RB: Last observation: looking at JP here as there seems to be some overlap between this and the empirical telephone number verification case? JP: Return routability tests of various kinds have been used for some time - stolen from practices used for email. If the endpoint is smart enough you could add more on top to strengthen the verification (e.g., crypto in the SIM card), or identifiers (IMEI, IMSI) that are maintained by the network therefore the network can be queried. If we want to make this more generic by defining a profile that encompasses both return routability tests, I'd be willing to work with you (Alexey) on that, if you are interested. AM: Sure. See slides (#6) for open issues. Main document wrap-up --------------------- Who: Richard Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-acme-acme-acme/ I-D: https://tools.ietf.org/html/draft-ietf-acme-acme-08 On proactive issuance, i.e., when to send the CSR? (See slides for details about requirements and alternative flows.) RB: One approach is to always send the CSR twice (PR#342). Simple logic (no branching), but unnecessary caching on client side if client always talk to a CA that caches the CSR + retransmit cost. (?): How do you know the two CSRs are the same? RB: This issue always exists when you send it twice EKR: Maybe... (long argument which I could not get.) RB: The other approach is CA signals client whether to do the second transmission. Another way you can view this dicothomy is whether the first and second requests are part of the same flow, or decoupled things. The first request is more or less a stateful thing that just gets advice and the second one (when you need a second one) as the actual issuance transaction. The more decoupled case that EKR was mentioning just now has the benefit that you only spend as much caching and bandwidth as you need to for a given CA and transaction - you don't cache the CSR if you don't need to. As EKR was mentioning you get this decoupling where there doesn't need to be any coupling between the first and the second requests and so you can have a slightly simpler logic on the server by just considering each request on its own without having to bind sequence of requests together. In this case the logic on the client is a little more complicated because it has to switch between the two cases. JL: why do you need the first CSR? RB: one of the use cases for getting the CSR upfront is that of legacy APIs that you might have behind an ACME interface that require the CSR at the beginning of the process. In this case first and second CSR are required to be the same because the backend has done everything based on the first CSR. RB: The question I have for the working group is which of these two approaches do we prefer? Had some discussion already on the list on PR#342. Personally I prefer PR#350 because it keeps things a little more decoupled and avoids unnecessary retransmits, but not a strong opinion. JHA: strongly prefer the former (PR#342) or, should I say, strongly disprefer the latter (PR#350). Main reason: I want to avoid that "this CA does something this way and that CA does something that way"; the risk is proliferation of clients that only implement one behaviour and not the other and then we don't have an interoperable ecosystem. Prefer simple and straightforward solution. EKR: not a crazy concern, but this is what interop testing is for, and actually having sensible protocol hygiene is more important. And what the security requirements are in term of what the CA needs to check between the two CSRs? JHA: CA can hash the two and make sure the hash is the same. EKR: That means you think they have to be the same, why do they have to be the same? JHA: I don't think this is necessarily true. EKR: This is concerning. JHA: In our setup and policy it's OK if they are different. I proposed hash equality because I thought you wanted them to be identical, but if you don't think so, I don't either. RB: There are cases (legacy API) where the CA requires them to be identical. RB: If you do the checks before issuance on the second one then it doesn't matter what the first one was... EKR: yes, but only as long as the protocol says you have to issue off the second one. RB: yeah. you say you do all your pre-issuance checks on the 2nd one. EKR: but again, protocol has to say if they are the same or not. I see great opportunities for screwing things up in a bunch of different ways. JHA: I agree. Would you be happy with PR#342 if we said the in the 1st CSR the public key and extensions are ignored and the only that matter is the 2nd one? EKR: I'd be happy-er RB: we could say: whatever checks the CA does on an issuance request have to be done with regard to the CSR that is sent in the 2nd request? EKR: no MT: what aspects of the CSR are needed in order to tell the client what to do? It's only the identifiers, right? RB: issue with legacy APIs that need a real CSR. EKR: why unify the two flows? Can't this be separated in two different flows with the server advertising which one to follow? JHA: I think only one of the flows would get implemented. There are 50-100 ACME clients which are essentially letsencrypt clients... how to build the protocol so that clients have an incentive to work with everyone? EKR: (summary) this seems the wrong way to go JHA: ideally, first round send just the identifiers, second round send the full CSR. we'd need to hear from CAs that have an API that needs CSR first and would have trouble adopting ACME without this flow. EKR: it seems you and I prefer the same thing (PR#342). I still need to be convinced we need "CSR first" flow. RS (no hat): could we make the error code generic so whenever you get this error code, resubmit with the CSR and if the CSR is resent it MUST be the same one? JHA: could work RB: need to see the PR to understand exactly how it'd work RB: surprised that PR#342 works with LE workflows with wildcards? JHA: the identifier notion introduced in PR#342 is a little different from the identifiers in the authorisation objects. RB: so basically in PR#342 you'd take the collection of DNS name SANs, translate them to identifier objects and send them in? JHA: yes MT: I like PR#342 as well, an editorial note: be more precise the definition of identifiers (e.g., define what it means to have a wildcard ID and the format of it) RB: there seems to be a bit of mass behind PR#342. Having a signal in the directory object to take care of legacy whereas the the core ACME is focused on going forward use cases. Then clients can implement the legacy affordance or not. YN: let's take a hum. Proposed way forward is accept PR#342. Hum if you understand PR#342. room: huuuuum YN: Hum if you don't room: (silence) YN: hum if you agree this is the right way forward room: hum YN: hum if you don't agree this is the right way forward room: (silence) RB: I'll work with Daniel to get PR#342 landed and talk with folks who have legacy APIs and see if we need to add some affordance for backwards compat. RB: Have this done and review comments incorporated by early December. RS: Kathleen, assuming this is the only substantive technical issue, do you want us to do another WGLC? Or just move it forward after like a week? KM (AD): as in TLS, do a narrowly focused WGLC on only areas of question, not the whole thing. Would be nice to have this done soon so that it doesn't need another AD review. The sooner the better. RB: Hope to get this done well before March. Telephony --------- Who: Jon Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-acme-acme-stir/ I-Ds: https://tools.ietf.org/html/draft-peterson-acme-authority-token-00, https://tools.ietf.org/html/draft-ietf-acme-telephone-01 JP: both I and Mary are presenting basically the same material and trying to pose the same questions. Trying to cover both as much as I can. JP: in STIR we have defined certificate profiles and a certain number of certificate extension. Two branches: TN (telephone numbers, maybe associated with an end-user) and SPC (service provider codes). It'd be very difficult, maybe impossible to administer those without something like ACME. See slides (#3-7) for a description of how STIR works, and how STIR plans to make use of ACME, and what the alternatives to prove identities are. JP: Generalising off the telephone use cases: an ACME server has a preexisting relationship with an identity authority of some kind; when a user claims a certain identity, the ACME server can challenge the user asking it to go to the authority that controls the relevant name space and get a token; if the authority thinks user is legit, they will give back something cryptographically signed that the user can present to the ACME server; if the ACME server verifies that "something" it issues the user a new certificate. JP: Other possible use case: E-ZPass / FasTrack with license plate authority. JP: Therefore define a generic token, with an explicit type governed by some registry and some more things in it (like a hint). JP: Mary's approach is slightly different, we want to check with the ACME WG whether this is a good idea, and which way is preferable. (?): clarifying question: you sort of imply ACME service reaching out to the authority to get the token? JP: no Who: Mary Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-acme-acme-token-identifier-and-challenges/ I-Ds: https://tools.ietf.org/html/draft-barnes-acme-token-challenge-00 https://tools.ietf.org/html/draft-barnes-acme-service-provider-code-00, https://tools.ietf.org/html/draft-ietf-acme-service-provider-02 See slides (#2-?) for an overview. MB: (audio breaks lots) JP: I'm arguing for a model with sub-typing and an IANA registry that specifies how these tokens work in particular. The approach in Mary's draft is more focused on identifying that entity designation than on something that could potentially use different forms of tokens. CW: Jon covered it pretty well. Service provider corresponds to the SHAKEN stuff that we've done in the STIR domain in terms of the service provider code. If I understand Jon's proposal, the difference is that instead of having a predefined entity code, we have a type that is defined in a profile document, or something like that, and that characterises all the claims and other things. My personal opinion is I'm fine with it. Wish Mary was here to give her position as well. MB: I have two drafts, one generic and another which provides an example of using the former. And in this model you woudn't need the registration and is therefore lighter weight in my opinion. It doesn't put as much knowledge of how we're doing this in the ACME server. So, it's totally up to the authority and its relationship with the end-entity to figure out the value of the token and the unique identifier. JP: yes, I guess it's lighter weight but since we have to assume a pre-existing association between the authority and the CA anyway, being lighter weight limits the kind of things you can end up talking about. MB: I see your point. I was doing it in the original service provider code document, where the perspective was that the PA and CA already have that trust relationship and in the SHAKEN model we absolutely have that. We have a more restricted model. I can see your point, OK. JP: I think this can be useful in lots of cases in ACME, but this is a question for the room, that's what I'm interested to hear about. MB: it doesn't cost anything to not be generic. My concern is if we are too generic we are going to get use cases that we need to evaluate and make sure it works for those situations. People have already implemented the SKAKEN stuff and it works... RB: I think this is worth doing generically. I've had a similar use case in mind for DNS names for a while. Wouldn't it be nice even for the DV case if the CA could get information directly from a registry as to who holds which domain name? It's worth at least including that case. The thing we need to struggle with here is what the right axes for generalisation are. The only draft I read is Jon's and it looks roughly correct to me in terms of branching on token type. I'm broadly supportive of this approach. CW: I agree it'd be good to have a generic approach. One thing we could do is having sort of a default mode where there is e.g, an UUID. I can see a scenario where 80-90% of the folks using this may have pretty much the same mechanism: you don't have to necessarily define every single use case - may be something to consider. RS: we already adopted both. If they are converging, authors should get together and merge. JP: if we merge Mary's and mine proposal, both the service provider draft and the TN document would then rely on the generic one. And I'm happy to put in Chris's UUID case as I think it makes a lot of sense. I love the DV case. I think it's a win-win. RS: Mary opinions? MB: Jon, Chris and I will work together. TH: I generally like the mechanism you guys are converging on. A slight thing on the amount of domain knowledge that you need and I think that you still require some amount of it in the CA to know something about (let's call it) the number space that you are eventually going to issue the certificate for, because I don't think you can get away from the fact that in STIR a wildcard means something and in regular domain name FQDNs it means another thing. Let's just try and not be so generic that we expect every CA to be able to have the knowledge to issue certificate of fundamentally different types. RB: just to clarify the context: the context is within an authorisation transaction at which point you have already specified this is the specific identifier you are validating. So, I don't think we run into the questions of wildcards, etc. TH: I agree, I'm just trying to say that the amount of state can only get so low, because you are going to be able to match it to what kind of identifier is going to be issued. There are some of these identifiers which are functionally issued with only one reference authority and the amount of state you are willing to take is whatever the reference authority requires. CW: you also have to assume that the ACME implementation needs to support STIR certificates as well so there are a couple of levels of qualification that have to happen before you can actually give a certificate. YN (chair): guidance is talk together and come back with a single submission and then we can call for adoption, hopefully before London. JP: OK RS (chair): do we need to hum on that? Is everyone fine? If the charter has to be adjusted we'll deal with that. Idea is to have this as a WG doc before London. RB: there shouldn't be any need for charter adjustments. RS: It depends on how generic you guys make it. STAR ---- Who: Thomas Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-acme-acme-star/ I-D: https://tools.ietf.org/html/draft-ietf-acme-star-01 See slides (#3-8) for a summary of the changes since Prague. JP: with my use case which is not domain names. I do appreciate the de-lurkage that you did thus far. The term DNO, and the notion that there is a domain name owner that cancels an automatic renewal still doesn't fit the language of my use case, but I'd love doing exactly what you are doing. So, just a little bit less specificy of the domain name part of this and STIR would totally use this. Happy to help. TF: OK, thanks. TF: interaction with certificate transparency is TBD. Diego went to the TRANS WG session to present the problem. DL: No conclusive answer whether this would pose a problem to CT or not. What I've heard from Melinda was they are OK for documenting the problem and solution space. What is not completely clear is where this work would be done since TRANS may be closing down in the next few months. DL: If others that were there (EKR?) could share their impression as well? EKR: AD hat off. Given clock skews forces short-term to be not below 7-days-ish, the increase in ingestion rate should be fine. So, no actual problem here, you should just go forward. RB: CT shall arrive at some solution for short-lived certificates anyway, regardless of this document, because there are multiple different fronts from which this is coming. So it seems it's their problem, not a problem for this document to solve. RB: One quick question out of curiosity: any CAs interested in deploying this? TF: Yes, Digicert contacted us; they said they have "short" as short as 8 hours.