Stephen Farrell has entered the following ballot position for draft-ietf-sidr-publication-10: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Why is sha-256 hardcoded? You could easily include a hash alg-id even as an option and in that way get algorithm agility, as called for by BCP201. (Or you could use something like ni URIs but that's a bit of a self-serving suggestion;-) Anyway, what's the plan for replacing sha-256 here? (This is a bit of a subset of Alissa's discuss with which I agree.) One possible way to handle this here is to identify sha-256 as the default hash algorithm but to re-define the ABNF for hash to allow an alg-id of some sort to be included there. Or have some generic versioning text somewhere that calls for a version bump if sha-256 is not to be used. (If the authors want to include this as a part of the discussion of Alissa's discuss, I'm fine with that and with clearing this discuss and letting the disucsion happen on that thread. But since the solutions could differ, I wanted to at least start a separate discussion on alg. agility.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - general: I think a design that uses https with mutual auth would have been better and easier. But given that this is implemented and deployed, I guess it's too late for this one. - As with the oob spec, the xmlns values get me a 404. - section 6: I don't agree that CMS signed data means that https is not needed. The latter provides confidentiality and integrity and server auth which the former does not. And even ignoring the security reasons, https is arguably much easier to deploy and requires less development. And http is vulnerable to middlebox messing (e.g. a client using http is more likely to be forced to support cleartext proxy-auth passwords). I would encourage you to encourage use of https with server auth in addition to CMS signed data payloads. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
