[secdir] Re: draft-ietf-lamps-rfc5273bis-08 ietf last call Secdir review

[Sean Turner <[e-mail]>]

Thanks for your review. I created an issue to track this here (lots of sub-issues):
https://github.com/lamps-wg/cmcbis/issues/146

> On Sep 5, 2025, at 17:37, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> 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.

That is the plan! We got ‘em all on the same telechat and Deb can control when they are get pushed forward. Joe and I made sure to all three of the I-Ds include a 6402 obsoletion header.

> ### 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.)

You’re right the “simple” requests/responses are single so there’s nothing to say about them - and .p10 is also binary (according to the Media Type registration) and implementations that support .p7c need to support binary (according to 8551).

s4.1 and s4.2 indicate binary and I am pretty sure that this was done to maintain feature parity there.  Would this be better:

OLD:

 When files are used
   to transport binary, Full PKI Request or Full PKI Response messages,
   there MUST be only one instance of a request or response message in a
   single file.


NEW:

 When files are used
   to transport Full PKI Request or Full PKI Response messages,
   there MUST be only one instance of a request or response message in a
   single file and the file MUST be binary encoded.

see: https://github.com/lamps-wg/cmcbis/pull/148

> ### 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?

The only thing I can think of is that it helps with automation.  And, this is ancient history so I am basically guessing. Actually now that I jump all the way back to RFC 2797 (circa 2000), it has the same requirement. I’d be a little worried about dropping it at this point and breaking interop with whatever is out there. 

> ### 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).

So we got Julian’s review:
https://mailarchive.ietf.org/arch/msg/spasm/gUelJ48nSiEULPvPBC89MbmLDFM/
We’ll start picking through it now.

> ### 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".)

Would this work:

OLD:

Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce attributes described in {{Section 6.6 of CMC-STRUCT}}.

NEW:

[Implementers/Deployers] of this protocol need to carefully consider environmental conditions before choosing whether or not to [implement/use] the senderNonce and recipientNonce attributes described in {{Section 6.6 of CMC-STRUCT}}.

See: https://github.com/lamps-wg/cmcbis/pull/152/

> ### 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.

Agreed not entirely sure where I’d point.  In this context, it’s basically saying if you want to setup a protected channel between your EE and RA/CA you need to some extra work and don’t take short cuts.

> ### 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.

This was really the point. I’d sugest changing it to:

OLD:

   In these instances,
   the Enveloped Data content type (Section 3.2.1.3.3 of [CMC-STRUCT])
   must be used to provide the same shrouding that TLS would have
   provided.

NEW:

   In these instances,
   the Enveloped Data content type (Section 3.2.1.3.3 of [CMC-STRUCT])
   provides the same shrouding that TLS would have provided.

see: https://github.com/lamps-wg/cmcbis/pull/161

> 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).

I guess I’m somewhat confused by this comment. Since CMC uses CMS if you want to shroud it can use EnvelopedData (more on AuthEnvelopedData later), so this addresses all of the instances where you wouldn’t have had prior trust relationships.

No problem adding some text about running SMTP over TLS, but isn’t that addressed by para #2?

> And I guess the analogue for the file-based protocol is file permissions,
> which we don't currently talk about at all (we should).

I would be happy to add something, but what? Tracking via:
https://github.com/lamps-wg/cmcbis/issues/162

> ### 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.

Is this what you’re looking for:

OLD:

   Reusing one connection for multiple successive requests, instead of
   opening multiple connections that are only used for a single request,
   is RECOMMENDED for performance and resource conservation reasons.

NEW:

   Reusing one connection for multiple successive requests, instead of
   opening multiple connections that are only used for a single request,
   is RECOMMENDED for performance and resource conservation reasons.
   The client MUST wait for the full response before making another request
   on the same connection.

See: https://github.com/lamps-wg/cmcbis/pull/154

> ### reference classification
> 
> I think erratum3593 is not a normative reference, since we have incorporated
> all of its content into this document already.

see: https://github.com/lamps-wg/cmcbis/pull/156

> ## Nits
> 
> ### BER
> 
> Do we need a reference for BER? (X.690 presumably.)

sure, see: https://github.com/lamps-wg/cmcbis/pull/158

> ### 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?

I cannot think of a reason why we couldn’t, but this change isn’t small. It would require:
- a new sections in s3.2.1.3 of -rfc5272bis
- new figures in s5 of -rfc5272bis
- debate about whether EnvelopedData or AuthEnvelopedData is the “primary”
- debate about whether the encryptedPOP/decryptedPOP control should also change
- new algorithm requirements in -rfc5274bis

Will need to think about this one a bit. Tracking via:
https://github.com/lamps-wg/cmcbis/issues/159

Cheers,
spt