Deb Cooley has entered the following ballot position for draft-ietf-emu-bootstrapped-tls-08: 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-emu-bootstrapped-tls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Finally a specification I understand! :^) While these comments are non-blocking, I'd like to see them addressed. Section 1.4: NAI? [I'd add this to Section 1.1] Section 6, third bullet: SHA-256 is very suitable for this function in the foreseeable future (to address the review comment). ECDSA for authentication will need to be replaced when CRQCs are readily available (i.e. attack in real time is possible). - no change requested for either. Section 6 or 7: I would add, 'The BSK public key MUST NOT be freely available on the network'. Trust for this method is completely dependent on this, stating this early and often isn't a bad thing. Section 7: The compressed ECDSA key pair needs to be correctly generated and validated. I think this could be a simple statement with a reference to FIPS 186-5, section 6.2, while RFC 5480 covers compressed points. Normative References: You also need a reference for ECDSA and generation of key pairs. Possibly: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf Normative References: You need a reference for ECDSA w/ compressed points. Possibly: RFC5480 (I don't think RFC 8813 covers this part). _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
