[lamps] Re: Using cms-kemri this CMP Indirect POP

["Brockhaus, Hendrik" <[e-mail]>]

Russ: 

 

I see your point in the sender offering both methods to let the recipient
chose, which generally eases interoperability. 

But so far, I do not see any convincing argument that it is really necessary
to requiring the sender to use any specific method to generate rid at all
because the recipient can easily ignore the rid field.

 

Currently I did not see any CMS implementation using method 4 from RFC 7093
Section 2 for generating recipient identifier. Typically, CMS implementation
simply use the data from the certificate of the recipient. I our case the
sender could simply use this standard procedure because the certificate is
available in on sender side in clear (not encrypted). 

Are you aware of CMS implementations offering the flexibility of specifying
the method for generation rid?

 

 

Hendrik

 

Von: Russ Housley <[e-mail]> 
Gesendet: Montag, 1. Juli 2024 20:57
An: David von Oheimb <[e-mail]>
Cc: Brockhaus, Hendrik (T CST SEA-DE) <[e-mail]>;
[e-mail]
Betreff: Re: [lamps] Using cms-kemri this CMP Indirect POP

 

David:

 

I think the CA should do Method 1+2, and the the client side should do
whatever is most straightforward for the implementer.  I see no reason for
the client to trow an error if the rid is a value other than expected as
long as it is able to figure out what private key to use in one way or
another,.

 

Russ

 





On Jul 1, 2024, at 2:35 PM, David von Oheimb <[e-mail]
<mailto:[e-mail]> > wrote:

 

On 01.07.24 19:40, Russ Housley wrote:

Hendrik: 

 

The transactionID from the CMP message header can be used by the recipient
to determine the appropriate private key to use, and the rid can be set to
the hash of the public key.  I do not see how this leads to the
interoperability concerns that you list under method 2.

What Hendrik meant with potential interop topic is that the implementations
on sender and receiver side must agree on 
the method for generating the key id, which might go wrong and which is
something simply not needed with method 1.

BTW, as mentioned in
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Flamps-wg%2Fcmp-updates%2Fissues%2F62&data=05%7C02%7Chendrik.brockhaus%40
siemens.com%7Cc95c0945a28b493afa4e08dc99ff9979%7C38ae3bcd95794fd4addab42e149
5d55a%7C1%7C0%7C638554570276887056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WHggTTd
hT0aitds4j%2FmMB%2FBPiexFsODWAe%2Bpgfqk79Y%3D&reserved=0>
https://github.com/lamps-wg/cmp-updates/issues/62., most implementations
will (need to) do method 1 anyway,
since this is the typical simple way a CMS API is designed (at least for
OpenSSL, and I suppose for most/all others, too),
and method 2 is an optional thing that may be done in addition (for an early
sanity check before decryption).
So the choice boils down to doing just method 1 or methods 1+2.

    David

 

On Jul 1, 2024, at 12:32 PM, Brockhaus, Hendrik
<mailto:hendrik.brockhaus=[e-mail]>
<hendrik.brockhaus=[e-mail]> wrote: 

 

Thank you to all for the good discussion on the list as well as on
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Flamps-wg%2Fcmp-updates%2Fissues%2F62&data=05%7C02%7Chendrik.brockhaus%40
siemens.com%7Cc95c0945a28b493afa4e08dc99ff9979%7C38ae3bcd95794fd4addab42e149
5d55a%7C1%7C0%7C638554570276900309%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=f0Lecx9
WgkwgrD1sPa9H2B6yipJWgzsrkAhzEvpg7B4%3D&reserved=0>
https://github.com/lamps-wg/cmp-updates/issues/62.

 

There were two methods proposed to identify the private key to be used on
recipient side for decryption of the EnvelopedData delivering the newly
issued certificate in encrypted form.

1.	Use a certificate management context, like transactionID from the
CMP message header and certReqId from the certificate request object.
2.	Use the SHA-256 hash of SubjectKeyIdentifier from the CSR by sender
and recipient as recipient identifier in the CMS recipienInfo field and do
not use the issuerAndSerialNumber or subjectKeyIdentifier from the new
certificate.

 

There are different people in favor of the one or the other method. I would
like to reach consensus on the method to specify in rfc4210bis until end of
this week to cover it in the update I plan to submit before the submission
cut-off.

 

Method 1:

Pros: 

*	Is specific to the recipient and does not raise any requirement to
the sender implementation. Using transactionID and certReqId can be used,
but any other context on recipient side is as good.
*	Is independent to the CMS implementation used because no specific
rid value needs to be used.
*	If there is only one certificate request pre CMP transaction the
context is trivial.
*	The sender can populate the rid field using the standard CMS method
using either issuerAndSerialNumber or subjectKeyIdentifier from the new
certificate.

Cons:

*	The recipient cannot doublecheck if the private key to use for
decryption is the right before decrypting the EnvelopedData.
*	The recipient must ignore the rid content.

 

Method 2:

Pros:

*	It is a clear specification on how to populate the rid field so that
sender and recipient must use.

Cons:

*	It introduces a potential interoperability topic an implementation
must properly address.
*	A recipient would need to reject decrypting the EnvelopedData in
case the sender is implementing the standard CMS method using either
issuerAndSerialNumber or subjectKeyIdentifier from the new certificate, even
if the decryption would work fine.
*	The certificate management context needs to be maintained anyhow
when implementing CMP.

 

Maybe I am a bit biased :-)

Does anyone want to add additional pros and cons to my summary?

 

 

Hendrik

 

 

Von: David von Oheimb < <mailto:[e-mail]> [e-mail]> 
Gesendet: Samstag, 29. Juni 2024 11:39
An:  <mailto:[e-mail]> [e-mail]
Betreff: [lamps] Re: Using cms-kemri this CMP Indirect POP

 

I had a closer look at this both from conceptual and implementation point of
view - 
see
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Flamps-wg%2Fcmp-updates%2Fissues%2F62&data=05%7C02%7Chendrik.brockhaus%40
siemens.com%7Cc95c0945a28b493afa4e08dc99ff9979%7C38ae3bcd95794fd4addab42e149
5d55a%7C1%7C0%7C638554570276909388%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vVXDa%2
FqpR0OvVEtrulcYmzOGgq%2BXGUp%2BJKUSMzB%2BNfY%3D&reserved=0>
https://github.com/lamps-wg/cmp-updates/issues/62 for details.

IMO its sufficient to let the CMP client application provide the CMS layer
the right decryption key,
namely the one corresponding to the public key it sent in the CSR in the
same transaction.
In the vast majority of cases, anyway just one such key is involved, and
otherwise they certReqId selects among those involved.

One might spend extra effort, both in specification and mostly in the
implementation on the server and client side,
in order to steer the generation of the RecipientIdentifer such that the
client is enabled to check the agreement of the en/decryption key
before decrypting the certificate in the response from the server, but this
extra sanity check does not really bring value.
The key selection can be done based on transaction and request ID, 
and successful decryption and use of the cert anyway implies that the
correct key has been used for decryption.

So my clear preference is to let the server-side CMS layer choose as usual
whatever RecipientIdentifer it is pleased to construct,
which may one that the client cannot really make use of before decrypting
the cert, and the client-side CMS lib can simply ignore it.

For instance, the existing OpenSSL CMS implementation checks for agreement
of the RecipientIdentifer
only if the calling application provides beforehand the cert corresponding
to the decryption key -
and this cannot be done in case of indirect POP, simply because the
(decrypted) cert is not available yet.

    David

 

On 20.06.24 08:10, Brockhaus, Hendrik wrote:

 

 

Von: Carl Wallace  <mailto:[e-mail]>
<[e-mail]>

 

 

From: Mike Ounsworth < <mailto:Mike.Ounsworth=[e-mail]>
Mike.Ounsworth=[e-mail]>





 

Hendrik,

 

Dumb question: does a CMP client actually need the rid in order to correctly
parse and decrypt the message? The client should know which keypair it is
trying to request a certificate for. Shouldn't the transactionID be
sufficient to determine which private key to use? Can the KEMRI simply be
left empty within CMP?

 

[CW] RID is not OPTIONAL. It'd be unusual to populate it with an empty OCTET
STRING, DN, serial. Mandating use of the key identifier option like Russ
suggested and letting implementations use it or not seems right to me.

 

[HB] You are right, we need to fill RID. 

But we are considering that the recipient does not use the content of the
recipient identifier for identifying the private key to use for decryption
in this case but use the CMP internal IDs transactionID and certReqId
instead. The advantage is, that this would only affect the implementation on
the receiving side. The sending entity could fill the recipient identifier
as usual with the subject key identifier from the recipient's certificate
and would not need to implement a specific method for generation the
recipient identifier as Russ proposed.

 

---

Mike Ounsworth

 

From: Brockhaus, Hendrik <
<mailto:hendrik.brockhaus=[e-mail]>
hendrik.brockhaus=[e-mail]> 
Sent: Wednesday, June 12, 2024 2:19 AM
To: Russ Housley < <mailto:[e-mail]> [e-mail]>; John
Gray < <mailto:[e-mail]> [e-mail]>; Tomofumi Okubo
< <mailto:[e-mail]> [e-mail]>
Cc: Ranjan, Rajeev < <mailto:[e-mail]>
[e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: [EXTERNAL] [lamps] Using cms-kemri this CMP Indirect POP

 

Russ, John, Tomofumi

 

While implementing Indirect POP for KEM in CMP we came across the following
issue, see
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Flamps-wg%2Fcmp-updates%2Fissues%2F62&data=05%7C02%7Chendrik.brockhaus%40
siemens.com%7Cc95c0945a28b493afa4e08dc99ff9979%7C38ae3bcd95794fd4addab42e149
5d55a%7C1%7C0%7C638554570276916354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BxCCy5f
B8SBp1jL%2BMi9pZrxlxPDPBi5FR%2FgoCkWkK24%3D&reserved=0>
https://github.com/lamps-wg/cmp-updates/issues/62.

 

Section 3 of cms-kemri says: 

"rid specifies the recipient's certificate or key that was used by the
originator with the KEM Encapsulate() function. The RecipientIdentifier
provides two alternatives for specifying the recipient's certificate [
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-e
ditor.org%2Frfc%2Frfc5280&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cc
95c0945a28b493afa4e08dc99ff9979%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7
C638554570276922568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sJ7qxGOXQZx0rGH%2FvS2e
DxzHuCb4HygxviGcroRUAtE%3D&reserved=0> RFC5280], and thereby the recipient's
public key."

When using Indirect POP, the recipient's certificate is delivered in
encrypted form. Therefore, the recipient does not know about
issuerAndSerialNumber or subjectKeyIdentifier before decrypting it and there
is no option to directly specify the recipient's public key.

Currently the cms-kemri implementation for Indirect POP in CMP need to spot
the private key to uses for KEM Decapsulate() by using the transactionID
from the PKIHeader and certReqId from the certificate request.

 

Is there a chance to get a third alternative in rid to directly specify the
recipient's public key. This would allow implementation to directly spot the
key pair to use.

 

Hendrik

 

_______________________________________________
Spasm mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail]
<mailto:[e-mail]>