Here are my comments on this draft. There is one that has broader implications (*). I'd like to see this addressed by the working group (specifically, why is there a need for multiple attestation challenges).
Also, I recognize that I'm posting these during the holidays. I certainly don't expect authors to respond until after the new year. Deb ---------------- Section 1, para 3: 'to be the most common use case'? Seems ambitious. How about, 'to be a common use case'. Rationale: why draw speculation about whether 'most' is true? Section 1, last para: 'at the time it was authored' change to 'at publication time of this specification'. *Section 1, last para: I am assuming that the authors believe the rats work is substantially far into the future? (Or why would we publish the challenge device-attest-01 if the rats work would replace it?). With any 'SHOULD' one needs to outline when one might ignore the SHOULD. Section 5, token: Please move the discussion on the generation of random values to Security Considerations. Also RFC 4086 is dated, please consider something like what is specified in draft-ietf-tls-rfc8446bis, Appendix C.1. [I recognize that this deviates from RFC 8555, but it is clearer to move a longer discussion to Sec Consid.] Section 6: Please reference RFC8555 for other security considerations. Section 7.3: What is the bullet 'Change Controller' meant to accomplish? Appendix A: I recommend that we add an 'Operational Considerations' section within the body of the specification (classically, just before Sec Considerations). RFC 5706 (or draft-ietf-opsawg-rfc5706bis) has more information on format and what might be included (most of which does not apply to this draft). I don't believe you need to do much more than move the contents of the Appendix into the new section. Acknowledgments: TO DO. Indeed. Nits: Section 1, last para: s/widley/widely
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
