I have CC: rats. I will prepare some slides for discussion at 124 at ACME, but I hope to propose them sooner, as some diagrams/time-sequences will probably help discussion.
There are some issues which are uniquely ACME, and some which are a bit more uniquely RATS. It may be worth splitting that up into two conversations. Or maybe everyone will be at ACME. [email protected] wrote: > Name: draft-liu-acme-rats Revision: 02 Title: Automated Certificate > Management Environment (ACME) rats Identifier and Challenge Type Date: > 2025-09-24 Group: Individual Submission Pages: 17 URL: https://datatracker.ietf.org/doc/draft-liu-acme-rats/ Diff: > https://author-tools.ietf.org/iddiff?url2=draft-liu-acme-rats-02 Hi, Mike, Peter and I have been working on this over the summer. (Mike Ounsworth joined as an author for -01) The introduction and use case section are amended/rewritten. This document now introduces: 1. a new identity type, "trustworthy" with a single value "trustworthy" This would be defended/authorized along with other identities, like DNS or FQDN or email. Previous versions mixed in the challenge into another identity, which was wrong. I thought it needed to go into newOrder, but that was also wrong. Thanks to Q for pointing out that challenges are *OR* within a single identity, but *AND* among identities. This is perhaps the weirdness part! Please feel free to argue this word: not attached to it at all. (You might prefer 11-random meaningless letters) 2. There are two challenges that can satisfy this identity. attestation-result-01: passport model. attestation-evidence-01: background-check model. (Note: one typo, this was "encrypted-evidence-01" before, didn't get completely changed in the Introduction, I see) 3. Authors do not yet have consensus about defining this more narrow (opinionated), vs allowing more options. This is a key topic for discussion should the document be adopted. 4. I think we did decide that while CMW is good, that we would recommend JSON/JWT-only, as ACME Servers and clients already have to have JWT, but do not have CBOR. For this use, either would be fine technically, but picking one is better. In some scenarios, particularly BYOD without a device manager, the Verifier for the device could well be the manufacturer of the device. So if I bring an iPad, Apple would be the Verifier, Samsung would do my Galaxy Tablet, etc. I think that this motivates Passport model, and simplifies the problem of evidence containing PII. However, that leaves the Attester picking a Verifier that it trusts, and which is also trusted by the RP/ACME Server. Background-Check does not really change the need to trust both, but it potentially changes how that choice is made! A concern is that the Appraisal Policy for Evidence might need to change based upon what the ACME Server expects for Attestation Results! That probably means for both methods that the Authorization object will need to contain some thing that indicates the desired kind of appraisal. Naively, I am thinking that it could be a policy/CPS OID, i.e. from RFC3647. However, AFAIK, those OIDs are essentially CA specific. There isn't AFAIK, a registry of common ones. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
