> On 23 Oct 2016, at 00:25, Paul Hoffman <[email protected]> wrote: > > Greetings. The draft can't make up its mind about SPKI pinning. In Section 3, > it says that SPKI-pinset-based authentication "is out of scope", but then > immediately admits that "Section 10 does describe how to combine that > approach with the domain name based mechanism described here". However, the > draft also talks about SPKI pinning in 4.2, 4.3.2, 5, 6, and then 10. Those > sections suggest (sometimes indirectly) that you might want to check both DNS > name and SPKI, but Section 10 then disavows specification of what to do if > only one of the two identifier types match. > > This is a mess. Either the draft has to give consistent, followable guidance > or defer to a different document. The latter seems much more likely to get > consensus than the former.
I agree that the current draft is muddied with these additional references but I think this is actually a relatively easy fix. The intension in the document was to treat as out of scope the details of _how_ to do SPKI authentication as they are described in RFC7858. What is (implicitly) in scope is how SPKI authentication can be used as an authentication mechanism within the general Usage profiles. So I would proposed clarification following lines: - Re-word the Scope along the above lines - Clarify that the Usage Profiles depend on the outcome of authentication (and encryption). - The authentication outcome is the result of one or more authentication mechanisms. Currently available mechanisms include SPKI authentication as described in RFC7858 and the domain name based authentication as described in this draft. - These mechanisms may be used independently or together. If used together all mechanisms must succeed for the authentication outcome to be successful. - tidy up the references you pick out based on this, for example, update references to ‘a valid domain name or SPKI pinset’ to ‘a valid authentication mechanism’ or similar I hope that would provide a clear and consistent picture? If so I can work on that update. Regards Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
