Thanks for the review Heikki. I have raises github issues to track all these, and will get them closed off soon.
https://github.com/upros/tls-pok/issues From: Heikki Vatiainen <h...@radiatorsoftware.com> Sent: Wednesday, October 2, 2024 5:43 PM To: EMU WG <emu@ietf.org> Subject: [Emu] draft-ietf-emu-bootstrapped-tls-06 clarifications, typos and minor issues A couple of typo and other, mostly minor, fixes follow. In regards to clarifications, the use of salt in Section '3.1 External PSK Derivation' is unclear but should be easy to clarify. Section '1.3. EAP Network Access' Suggest a small terminology update: s/perform an EAP-TLS-based exchange/perform a TLS-based EAP exchange/ Second paragraph has odd wording: Devices whose BSK public key _can been_ obtained Section '2. Bootstrap Key' Paragraphs 1 and 2 talk about ASN.1 encoding and formatting. I think the intention is clear, but the text could be clearer about ASN.1 notation (or syntax or definition) vs DER encoding. The first paragraph points to RFC 5280 (PKIX profile) for SubjectPublicKeyInfo defintion while later in section 3 SubjectPublicKeyInfo points to RFC 7250 (raw public keys). Would it be clearer for the both cases point to RFC 7250? The second paragraph gives an example of using QR code to making public key available. Just to be clear: when the QR code is scanned, the Base64 encoded characters decode to a DER encoded structure which is shown in Figure 2 or RFC 7250 (SEQUENCE with both algorithm and subjectPublicKey)? Based on the text I'd say yes, but it might be useful to be clear to say that this is the case so that no one thinks that e.g., algorithm can be left out because this document is always requires ECDSA key type. Section '3. Bootstrapping in TLS 1.3' Second paragraph has 'Certificate based' but the rest of the document, and RFC 8773, uses a dash: 'Certificate-based'. Section '3.1 External PSK Derivation' epskid derivation definition says: - <> is a NULL salt Can this clarified? For example, salt is: 1: 0 - a string of Hash.length bytes set to zero (RFC 8446 section 7.1) 2: Single all zero bits octet (ASCII NUL character) 3: An empty string, that is, a zero length salt Based on RFCs 5869 (HKDF-Expand and HKDF-Extract defintion) and 8446, I'd say option 1: is the correct. If possible, a test vector that shows the result of epskid derivation would be valuable. The document could have a Base64 encoded BSK public key as input information and hex or Base64 encoded epskid as output. This would tie together BSK public key encoding and the derivation it's used for. Section '4. Using TLS Bootstrapping in EAP' Last sentence of section 4 ends with '... , and _it not used_ for any subsequent network access.' Suggested change: s/it/is/ -- Heikki Vatiainen h...@radiatorsoftware.com<mailto:h...@radiatorsoftware.com>
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
