My appologies for having a conflict on this session. (Two even) And for not getting the document updated: seemed no point in writing more text that goes in the wrong direction, but OTH, having something more tangible to read would have helped.
Aaron Gable <[email protected]> wrote: > That said, my gut reaction is that it is a bad idea. The beauty of > ACME, in my opinion, is that it has an infinitely extensible collection > of identifier types, and an infinitely extensible collection of > challenges to validate those identifiers. If the thing that is > semantically happening is that the server is validating a claim that > the client is making, that should almost certainly take place as part > of the existing extensible identifier/authorization/challenge > mechanism, not get bolted on elsewhere in the protocol. This was in the original proposal. (I thought that around IETF122, that you actually reacted and said that newOrder would better. Maybe it wasn't you) I thought it was wrong: the challenges are for the client to defend/authorize a name that is going into a certificate. There is no identity that the Evidence/Attestation Results are going to support. Today, a client is given a list of possible ways to satisfy a name challenge, and it picks one. We may need to continue to do this. > I *believe* that the reason the design team has gone in this direction > is because the rats identifier does not appear in the final issued > certificate. Is that correct? I wouldn't say that's the way the argument went, but this summary is not wrong. > If yes, *why* does no corresponding identifier appear in the cert? If > the CA is enforcing that certain policies be met, then can't that be > represented by a Certificate Policies extension? And then you're in an > even better place, since enterprise clients can enforce that the > specific Certificate Policy OID be present before they trust a cert. It's not clear that > I'm imagining a world where the flow looks like this: 1. Enterprise > client requests a new order for internal.tld 2. Enterprise CA says > "sure, but only if you're up-to-date", and creates an order with two > identifiers: a. {"type": "dns", "value": "internal.tld"} b. {"type": > "policy", "value": "1.2.3.4.5"} (created by server policy, not because > client requested it) > 3. Enterprise CA creates a corresponding > authorization object, too, with the same "policy"-type identifier, and > two "rats-01" and "rats-02" challenges, representing different ways the > client can prove that it complies with the policy. > 4. The client > fulfills one of the challenges, and the authorization gets marked as > valid. *ONE* of the challenges. But more than one challenge needs to be done. > 5. The CA issues the cert, and includes OID 1.2.3.4.5 in the > Certificate Policies extension > --- > Regarding Q Misell's statement that RFC 8555 technically allows a > server to require multiple challenges for a single authorization: the > exact quote from Section 7.1.4 > <https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4>, in the > description of the `challenges` field, is: Each array entry is an > object with parameters required to validate the challenge. > A client > should attempt to fulfill one of these challenges, and a server should > consider any one of the challenges sufficient to make the authorization > valid. There's a similar statement later in Section 7.5.1 > <https://datatracker.ietf.org/doc/html/rfc8555#autoid-39>, which says > The server is said to "finalize" the authorization when it has > completed one of the validations. Yes. > So I at least partially agree that it's acceptable for a server to > require two different challenges to be fulfilled on a single > authorization before it considers that authorization valid. However, I > think doing this in practice would break virtually every ACME client in > existence. ! I had originally proposed putting the AttestationResult into the newAccount. It was explained to me that accounts are not per-machine in larger entities. (Whereas most of us are experienced with "certbot", where that is the case) That at a large hosting provider, the ISP is the account holder, and it creates many (many,many..) orders for each tenant. {The authorization to exceed enrollment limits is attached to the account} > In particular, most clients have very simple heuristics for > selecting which challenge to fulfill on an authorization. I expect > that, if a server accepted a challenge validation attempt but *didn't* > mark the corresponding authorization as valid, most clients would get > stuck in an infinite loop either polling the authorization until it > becomes valid, or retrying the same challenge type over and over again. > --- I'll read your specific comments later. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
