Subject: [lamps] Mail regarding draft-ietf-lamps-cmp-updates

From: Lijun Liao <[email-masked]>
Date: Fri, 11 Dec 2020 20:13:08 +0100

Dear authors,

I am extending my open-source project xipki to support this draft. In case
that the CA generates the keypair, it needs to send the private key
encrypted back to the client. In this draft, you change the type of
privateKey and encryptedCert from EncryptedValue to EncryptedKey.

Here the definition of EncryptedKey:
 EncryptedKey ::= CHOICE {
   encryptedValue EncryptedValue, -- deprecated
  envelopedData [0] EnvelopedData
}

If the CA uses the envelopedData choice, the CMP client that does not
support this draft, cannot process the response. So the CA needs a
mechanism to determine whether the CMP client supports this draft or not.
You should increase the CMP version or add some other fields in the CMP
request to provide the CA such information.

BTW, please change the following text block in page 4 (there is no section
2.1.9):

"RFC 4211 [RFC4211] section 2.1.9" to "RFC 4211 [RFC4211] section 2.1 point
9"

Best regards

Lijun Liao

---

From: Lijun Liao <[email-masked]>
Date: Fri, 11 Dec 2020 20:24:25 +0100

Sorry please ignore this email. It should be targeted to the authors (
[email-masked]).

On Fri, Dec 11, 2020 at 8:13 PM Lijun Liao <[email-masked]> wrote:

> "RFC 4211 [RFC4211] section 2.1.9" to "RFC 4211 [RFC4211] section 2.1
> point 9"
>
> Best regards
>
> Lijun Liao
>
>

-- 
Lijun Liao

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 11 Dec 2020 19:48:27 +0000

Dear Lijun Liao

Thank you for your email.
Nice to hear, that you are about to implement the changes.

> Von: Spasm <[email-masked]> Im Auftrag von Lijun Liao
> Gesendet: Freitag, 11. Dezember 2020 20:13
>
> Dear authors,
>
> I am extending my open-source project xipki to support this draft. In case that the CA generates the keypair, it needs to send the private key encrypted back to the client. In this draft, you change the type of privateKey and encryptedCert from EncryptedValue to EncryptedKey.
>
> If the CA uses the envelopedData choice, the CMP client that does not support this draft, cannot process the response. So the CA needs a mechanism to determine whether the CMP client supports > this draft or not. You should increase the CMP version or add some other fields in the CMP request to provide the CA such information. 

You are right, the backward compatibility is ensure, as the old and the new syntax are identical when using the choice Encrypted Value.
I think you are right, if a CA uses EnvelopedData instead, the client will not be able to parse the value.
Our idea was, that the client in this case responds with an error code, e.g., badDataFormat.
         badDataFormat       (5),
         -- the data submitted has the wrong format
But you may be right, may be it is clearer to increase the CMP version number. Then the CA knows in advance about the capabilities of the client.
Our goal was to make only minimal changes to CMP to circumvent increasing the CMP version. 
We discussed the different options with Jim Shaad in 2019. But sadly we will not be able to ask him for guidance any more. :-(

Are there other ideas out there?

>
> BTW, please change the following text block in page 4 (there is no section 2.1.9):
>
> "RFC 4211 [RFC4211] section 2.1.9" to "RFC 4211 [RFC4211] section 2.1 point 9"

Thanks for the hint!

Best regards
Hendrik

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Dec 2020 14:55:43 -0500

> On Dec 11, 2020, at 2:48 PM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Dear Lijun Liao
> 

When we have done things like this in CMS, we say when encryptedValue is used, the version MUST be X, and when envelopedData is used, the version MUST be x+1.  This allows an unsupported version error instead of a bad format.

Russ

---

From: Lijun Liao <[email-masked]>
Date: Fri, 11 Dec 2020 21:31:43 +0100

> You are right, the backward compatibility is ensure, as the old and the
> new syntax are identical when using the choice Encrypted Value.
This may not work, in many cases, there is only one round (request -
response). The client does not get the chance to send the CA this
error message. Even this is possible, we waste here one round, and the CA
have to cache the previous response. As I understand one of
the reasons to update the CMP RFCs is to target the IoT area, which is very
sensitive on the communication and computation consumption.
Increasing the rounds does not fit to such scenarios.

But you may be right, may be it is clearer to increase the CMP version
> number. Then the CA knows in advance about the capabilities of the client.
> We discussed the different options with Jim Shaad in 2019. But sadly we
> will not be able to ask him for guidance any more. :-(
>
Sorry to hear about this.

> Are there other ideas out there?
If you cannot increase the CMP version, what about adding a new
InfoTypeAndValue to the PKIHeader.generalInfo?

Best regards

Lijun

---

From: Lijun Liao <[email-masked]>
Date: Fri, 11 Dec 2020 21:41:20 +0100

When we have done things like this in CMS, we say when encryptedValue is
> used, the version MUST be X, and when envelopedData is used, the version
> MUST be x+1.  This allows an unsupported version error instead of a bad
> format.
>
> Russ
>
> This solution helps the client to determine whether it can parse the
received response. And in my opinion should also be implemented. Otherwise
the client has to parse (almost) the whole received response before it
detects the unsupported feature.

The request should also contain information, e.g. different version
numbers,  indicating the client's capabilities, namely whether it can parse
the envelopedData choice or not.

Lijun

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 15 Dec 2020 09:18:40 +0000

Russ

> -----Ursprüngliche Nachricht-----
> Von: Russ Housley <[email-masked]>
> 
> mechanism to determine whether the CMP client supports > this draft or
> not. You should increase the CMP version or add some other fields in the
> CMP request to provide the CA such information.
> >

Can we stick to the concept of updating RFC4210 when introducing a CMP V3 version for usage of EnvelopedData?
Or does the introduction of a new version number requires to obsolete RFC4210?

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Dec 2020 11:21:38 -0500

> On Dec 15, 2020, at 4:18 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
> 

I do not see a problem.

Russ

---

From: Lijun Liao <[email-masked]>
Date: Sat, 19 Dec 2020 21:21:39 +0100

What about the following suggestions
1. In the PKIHeader add an InfoTypeAndValue to the generalInfo field. This
new element contains the supported CMP versions of the sending party.
2. The CMP version is set to 3, if the PKIMessage contains fields not
conforming to RFC4210.

- Lijun

-- 
Lijun Liao

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 21 Dec 2020 11:04:38 +0000

Hi Lijun

I can see your point and tend to prefer the suggestion of Russ.
Therefore I investigate what needs to be updated in CMP Updates to introduce a CMP V3 only in case EnvelopedData is required in a transaction and supported by the client.
Currently I think in RFC4210, next to section 5.2.2, sections 1, 5.1.1, 7, D.1, and F need to be updates. May be sections 5.3.4 and 5.3.19.9 would also need an explanatory note.
Do you see further sections that need updates?

Hendrik

Von: Lijun Liao <[email-masked]>
Gesendet: Samstag, 19. Dezember 2020 21:22
An: Russ Housley <[email-masked]>
Cc: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; [email-masked]
Betreff: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates

What about the following suggestions
1. In the PKIHeader add an InfoTypeAndValue to the generalInfo field. This new element contains the supported CMP versions of the sending party.
2. The CMP version is set to 3, if the PKIMessage contains fields not conforming to RFC4210.

- Lijun

On Tue, Dec 15, 2020 at 5:21 PM Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

> On Dec 15, 2020, at 4:18 AM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:
>
> Russ
>
>> Von: Russ Housley <[email-masked]<mailto:[email-masked]>>
>>
>>> On Dec 11, 2020, at 2:48 PM, Brockhaus, Hendrik
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Lijun Liao

I do not see a problem.

Russ

--
Lijun Liao