Mahesh Jethanandani has entered the following ballot position for draft-ietf-uta-tls13-iot-profile-23: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Roman's COMMENT flags RFC 7452 as apparently unused. I did a full pass over the body text and agree — I don't see it cited anywhere outside the reference list. Should come out, or get an in-text citation if one was intended. --- On Ketan's reference-classification DISCUSS: I think he's on solid ground for RFC 7301 and RFC 7250, but RFC 6066 strikes me as a different case. Section 12: 504 > Implementations conforming to this profile MUST support ALPN. A MUST-level requirement to support an extension defined entirely in RFC 7301 is about as clean a case for "normative" as reference classification gets. Something similar applies to RFC 7250, given the MUST-level digital-signature and key-exchange requirements this profile attaches to raw-public-key support in Section 3. RFC 6066, though, at least for me, only shows up in MAY-level, illustrative contexts — the Trusted CA Indication extension and the client certificate URL mechanism in Section 19 are both explicitly optional, deployment-specific techniques, not things a compliant implementation has to do. RFC 6066 should stay informative. --- Section 17.1.3, close to Roman's question about "or stronger" being unclear: 655 > The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758]. I checked RFC 5758 directly: it defines ecdsa-with-SHA224/256/384/512 as four distinct algorithm identifiers but doesn't itself establish a strength ordering among them — it points out to NIST SP 800-57 for that. So "or stronger" isn't a term RFC 5758 defines; the ordering is imported from outside the cited reference. Not wrong, but worth being explicit that "stronger" means "a SHA-2 variant with a longer digest," since that's not spelled out here or in RFC 5758 itself. _______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
