Document: draft-ietf-lamps-rfc5273bis Title: Certificate Management over CMS (CMC): Transport Protocols Reviewer: Benjamin Kaduk Review result: Has Issues # secdir review of draft-ietf-lamps-rfc5273bis-08 CC kaduk I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is "on the right track". This is in a certain sense a simple document, but it's also artifact of its predecessor's times, and given the current protocol ecosystem and level of understanding, there are a number of ways in which we can and should say more than RFC 5273 did. Thank you for including section 3 with the changes since the previous RFC(s)! I made a pull request with some additional editorial suggestions: https://github.com/lamps-wg/cmcbis/pull/123 ## Comments ### Obsoletion This document claims to make RFC 6402 obsolete, but really we can only handle Section 3 of that RFC. I see that there are 5272bis and 5274bis documents in flight as well, which would collectively take care of all of 6402. Perhaps we should have an RFC Editor note to highlight the situation and attempt to ensure that all three are published together with the joint obsoletion. ### binary requests In §4 (File-Based Protocol) there's a line about "When files are used to transport binary, Full PKI Request or Full PKI Response messages" and a table that lists four message types. I'm not sure I understand what the "binary" maps to -- initially I thought that the comma was a typo and we're just clarifying that the Full PKI Request/Response use binary encodings, but then I started to wonder if "binary request or response" refers to the .p10 and .p7c formats. For what it's worth, "binary" only appears in RFC 5727 in comments describing what's in the example message exchange, so I'm inclined to believe that "binary reqest/response" is not currently a CMC term of art. (I also kind of expect that the "simple" requests/responses, by nature of their file type, can only contain a single request/response and so there's no need to specifically state a requirement, which tends to support the theory that the comma is a typo.) ### File names For the mail-based protocol (§5), we require that a file name be specified (either via Content-Type or Content-Disposition), but I'm failing to find any justification or motivation for why this filename is needed. What is it supposed to be used for? ### HTTP I hope that httpdir can take a look (I do not see a review request for them, though), as there may well be a lot to say about the HTTP usage here. Specifying the specific response code 200 is probably not considered best practice for application specifications at this point. (Specifying to use POST is good, though.) I'm surprised we don't say anything about how to know what URL path to make the POST to, even to leave it out of scope. (I suppose a similar thing could be said about the file-based protocol.) Servers in general cannot expect support for any type of HTTP authentication, though perhaps it's reasonable to reiterate that here. I might try to frame it as more of a declarative statement that CMC over HTTP is using HTTP solely as transport and does not expect to make use of HTTP functionailty such as X/Y/Z, though. I'll also try to help the usage of HTTP terminology in my editorial PR (of particular note, the PKI Response section seemed to assume HTTP/1.x usage). ### Replay considerations I think the guidance about carefully considering environmental conditions (§9) applies at least as much to deployers of this protocol as to implementors, so we should probably update the target of our guidance here. (Perhaps this expands to "choose your implementation carefully" as well as "choose to implement".) ### Generally accepted principles of secure key management It's a bit unfortunate that we are using such vague language about "strongly encouraged to consider generally accepted principles of secure key management" in the security considerations, but I'm not sure that I have a particular reference that I would suggest pointing to for discussion of these topics. ### content shrouding We have a nice note (§9) about using EnvelopedData to provide content shrouding in cases where TLS cannot be used. But this is the security considerations section; we should talk about what the risks are and why one might want to have some kind of content shrouding at all (whether via TLS or EnvelopedData)! It's also interesting to note that the phrasing is "EnvelopedData ... must be used" (lowerase must), which leaves it unclear whether there's an analogous requirement to use TLS when it's possible to use TLS. Perhaps we're just saying that EnvelopedData is the only way to get content shrouding when TLS is not available, in which case we probably want to avoid a "must be used" construction. Content shrouding is not exactly available for the mail-based protocol, which should get a mention (and thus suggestion to use EnvelopedData there as well, or perhaps operationally ensure that SMTP is going over TLS). And I guess the analogue for the file-based protocol is file permissions, which we don't currently talk about at all (we should). ### TCP pipelining I think that it is probably not safe to attempt to "pipeline" requests over a TCP connection (starting to send another request before the full response has been received to the first request), but we only implicitly at best cover this situation. I'd suggest making a clear statement about whether or not the client needs to wait for the full response before making another request on the same connection. ### reference classification I think erratum3593 is not a normative reference, since we have incorporated all of its content into this document already. ## Nits ### BER Do we need a reference for BER? (X.690 presumably.) ### AuthEnvelopedData Is it okay to use AuthEnvelopedData as well as EnvelopedData? Or is it not possible to do so based on the key-material situation? ## Notes This review is formatted in the "IETF Comments" Markdown format, see https://github.com/mnot/ietf-comments. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
