[lamps] Feedback on figure 3 in draft-brockhaus-lamps-lightweight-cmp-profile-01

[Justin Cranford <[e-mail]>]

Hello,

Figure 3 shows the proposed message format for securely returning a remote generated privateKey to a lightweight CMP client.

- https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-01#page-31


Feedback summary:

1. CMS SignedData should be the outer layer.
2. CMS ContentInfo should be used to wrap both of the CMS EnvelopedData and CMS SignedData layers.
3. CMS Data may be useful to wrap the privateKey payload.



Feedback details:

1. CMS SignedData should be the outer layer.
a) When a lightweight IOT client receives a response, it should do the lightweight SignedData verification first.
b) In other words, if a lightweight client does heavyweight EnvelopedData decryption first, and SignedData verification fails second, the client just wasted a lot of processing power, battery life, and time.
c) CMS SignedData can be used to provide extra data needed by the client to decrypt EnvelopedData. Consider if client and server both use EC key pairs.
Example: EnvelopedData contains KeyAgreeRecipentInfo using static-static ECDH algorithm. Client needs the server EC public key to compute EnvelopedData KEK. Server options for the originator KeyIdentifier in KARI include IssuerAndSerialNumber, SubjectKeyIdentifier, or OriginatorPublicKey. If server chooses IssuerAndSerialNumber, the client must find the server's EC public cert. That somewhere can be the SignedData certificates set if-and-only-if SignedData is outside EnvelopedData.

2. CMS ContentInfo should be used to identify the CMS EnvelopedData and CMS SignedData layers.
a) The lightweight client's CMS parser can to do more strict verification of the response structure without incurring significant overhead.

3. CMS Data can be used to wrap the privateKey.
a) This is optional, but it might be useful to wrap the payloads.
b) If you choose to add a CMS Data layer, also wrap it with CMS ContentInfo like in point #2.



References:

I based my feedback on SCEP pkiMessage format from Gutmann SCEP draft 14. SCEP is a lightweight enrollment protocol with similar goals to lightweight CMP profile draft.

Gutmann SCEP draft 14 does a good job of explaining the structure of its secure pkiMessage format with different layers of ContentInfo, SignedData, EnvelopedData, and Data.

- https://tools.ietf.org/html/draft-gutmann-scep-14#page-13 (June 9 2019)

Gutmann inherited this message format from Nourse SCEP draft 23. However, Gutmann does a much better job showing and explaining the structure, so use the Gutmann reference.

- https://tools.ietf.org/html/draft-nourse-scep-23#section-3 (September 2011)

Here is a compact summary of the SCEP pkiMessage format. SCEP uses it for requests and responses.

- SCEP's pkiMessage = ContentInfo[SignedData[ContentInfo[EnvelopedData[ContentInfo[Data[payload]]]]]]


Summary:

Ignore SCEP payload formats since they are not applicable. Optionally use the same CMS Data layer.  Definitely put SignedData first, and consider adding ContentInfo wrappers for all CMS layers.

Thank you,
Justin Cranford
Prin Software Developer
Entrust Datacard