Hi! I just balloted YES with a few comments on draft-ietf-trans-rfc6962-bis. To follow-up on Paul's earlier summary [1], I saw that some discussion has occurred in response to the IESG ballot but wanted to check-in with the authors on the disposition of addressing the remaining DISCUSS items.
[1] https://mailarchive.ietf.org/arch/msg/trans/9zGMHr_Fu1EefWbvthvqSANl3nA/ ==[ Ben Kaduk From: https://mailarchive.ietf.org/arch/msg/trans/2Sc26GMFwQnTRl5DEEk_-51ABFU/ Item #1 Sections 4.11 and 4.12 have arrays of NodeHash to carry consistency and inclusion proofs, respectively, with minimum array size of 1. However, Sections 2.1.4.1 and 2.1.3.1 (respectively) seem to admit the possibility of zero-length proofs in degenerate cases, which the aforementioned protocol description language forbids the conveyance of. (Section 5.3 explicitly requires the use of an empty consistency proof.) Do those minimum array sizes need to be (implicit) zero? (If they do not, it seems that a minimum size of 32 would have the same effect as that of one, since a NodeHash has minimum size 32.) Item #2 In Section 6: o An Online Certificate Status Protocol (OCSP) [RFC6960] response extension (see Section 7.1.1), where the OCSP response is provided in the "CertificateStatus" message, provided that the TLS client included the "status_request" extension in the (extended) "ClientHello" (Section 8 of [RFC6066]). [...] This is not quite a TLS 1.3-compliant formulation -- TLS 1.3 does not use the "CertificateStatus message", but rather uses the encoding of that structure in a status_request extension in the CertificateEntry. draft-ietf-trans-rfc6962-bis === ==[ Mirja Kühlewind From: https://mailarchive.ietf.org/arch/msg/trans/0R9dKzZ4h2bLQX4pyHqwdA4uVdo/ There was a presentation at maprg IETF 103 about the question if CT helps attackers to find new domains. I think this risk should at least be mentioned in the security considerations section. [Roman] Pending review by Mirja. Section 11.6 was added. === ==[ Alexey Melnikov From: https://mailarchive.ietf.org/arch/msg/trans/qiURoDHiWrP1l7X3WY9RRvYrWFg/ 5. Log Client Messages type: A URN reference identifying the problem. To facilitate automated response to errors, this document defines a set of standard tokens for use in the "type" field, within the URN namespace of: "urn:ietf:params:trans:error:". I think you need to register this in <https://www.iana.org/assignments/params/params.xhtml#params-1> === Regards, Roman _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
