Subject: [lamps] draft-ietf-lamps-cmp-updates addressing errata?

From: Sean Turner <[email-masked]>
Date: Thu, 15 Jul 2021 14:27:05 -0400

Hi! I think the I-D need to address the outstanding errata:
https://www.rfc-editor.org/errata_search.php?rfc=4210&rec_status=15&presentation=table

0) in s2.9, the CertOrEncCert needs to be updated to replace 

 certificate     [0] Certificate,

with

 certificate     [0] CMPCertificate,

according to https://www.rfc-editor.org/errata/eid4078
because it needs to match the ASN.1 in the module.

1) s2.9 needs to be expanded to also replace:

CertRepMessage ::= SEQUENCE {
         caPubs          [1] SEQUENCE SIZE (1..MAX) OF Certificate
                             OPTIONAL,
         response            SEQUENCE OF CertResponse
     }

with:

CertRepMessage ::= SEQUENCE {
         caPubs       [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                          OPTIONAL,
         response         SEQUENCE OF CertResponse
     }

according to https://www.rfc-editor.org/errata/eid3949
because it needs to match the ASN.1 in the module.

2) s2.22 needs to be updated to address this errata:

https://www.rfc-editor.org/errata/eid2615

3) s2.4 needs to be updated to address this errata:

https://www.rfc-editor.org/errata/eid2616

4) s2.25 should consider addressing this errata:

https://www.rfc-editor.org/errata/eid5201

5) generally need consider addressing this errata:

https://www.rfc-editor.org/errata/eid5731

Once we get through these then we can tell Roman how to dispense with last two.

spt

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 16 Jul 2021 06:06:55 +0000

Sean

Thanks a lot for this hint. You are absolutely right, we should address as much errata as possible.
I will have a look into it.

Hendrik

> Von: Spasm <[email-masked]> Im Auftrag von Sean Turner
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> editor.org%2Ferrata_search.php%3Frfc%3D4210%26rec_status%3D15%26prese
> ntation%3Dtable&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%
> 7Cfdfc03540fb64af63fbc08d947be309d%7C38ae3bcd95794fd4addab42e1495d5
> 5a%7C1%7C0%7C637619704453788578%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&amp;sdata=ShO4YfOO326M3VnZSInrPrwmikTv8oApv7q1CVab8sA%3D&amp;r
> eserved=0
> 
> according to
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> editor.org%2Ferrata%2Feid4078&amp;data=04%7C01%7Chendrik.brockhaus%4
> 0siemens.com%7Cfdfc03540fb64af63fbc08d947be309d%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637619704453798573%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=%2FNvWiY8hD6xQ9hk0BT6uzPgYSlVw4lpK91GLE
> C2%2BUhQ%3D&amp;reserved=0
> according to
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> editor.org%2Ferrata%2Feid3949&amp;data=04%7C01%7Chendrik.brockhaus%4
> 0siemens.com%7Cfdfc03540fb64af63fbc08d947be309d%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637619704453798573%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=nRQbb465cv5YA%2F5uvgUtnaXtznIgm8w8wiUs5
> 0eUPRc%3D&amp;reserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> editor.org%2Ferrata%2Feid2615&amp;data=04%7C01%7Chendrik.brockhaus%4
> 0siemens.com%7Cfdfc03540fb64af63fbc08d947be309d%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637619704453798573%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=YmKpyGnI7B%2BH7rlre1mctykMm%2BDuvlL%2B
> maEkraSxVUE%3D&amp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> editor.org%2Ferrata%2Feid2616&amp;data=04%7C01%7Chendrik.brockhaus%4
> 0siemens.com%7Cfdfc03540fb64af63fbc08d947be309d%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637619704453798573%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=FQ%2BKnAamOUnkx%2FJB0WUkKq%2F7CtY1yZ
> TVyvHxj687n9k%3D&amp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> editor.org%2Ferrata%2Feid5201&amp;data=04%7C01%7Chendrik.brockhaus%4
> 0siemens.com%7Cfdfc03540fb64af63fbc08d947be309d%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637619704453798573%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=iTP9Ixz6w4JC9QuRTrb84pPu%2BNhNm8u6AaGIy
> Drj%2Bi8%3D&amp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> editor.org%2Ferrata%2Feid5731&amp;data=04%7C01%7Chendrik.brockhaus%4
> 0siemens.com%7Cfdfc03540fb64af63fbc08d947be309d%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637619704453798573%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=uEmp4ly3o04m%2FmIVO7QTCxgcrr7jiEu%2FVUy
> Gw8j6CI0%3D&amp;reserved=0
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.brockha
> us%40siemens.com%7Cfdfc03540fb64af63fbc08d947be309d%7C38ae3bcd9579
> 4fd4addab42e1495d55a%7C1%7C0%7C637619704453798573%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C1000&amp;sdata=HQxjGhVob%2Fq51hcvdw%2F4JrxrL2rofvu8
> M5vrf0jz7Ck%3D&amp;reserved=0

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 16 Jul 2021 11:45:37 +0000

>  certificate     [0] CMPCertificate,

Done with the next update of CMP Updates

>          response         SEQUENCE OF CertResponse

Done with the next update of CMP Updates

> 2) s2.22 needs to be updated to address this errata:

Done with the next update of CMP Updates

> 3) s2.4 needs to be updated to address this errata:

Done with the next update of CMP Updates

> 4) s2.25 should consider addressing this errata:

Done with the next update of CMP Updates

> 5) generally need consider addressing this errata:

This errata needs some more discussion, but I see the point.
David will provide some more detailed feedback.

Hendrik

---

From: David von Oheimb <[email-masked]>
Date: Fri, 16 Jul 2021 14:39:43 +0200

Hi Lijun,

yesterday Sean brought the existing RFC 4210 errata reports to our
attention - among others, an erratum that you provided.

This is what you wrote there:

> In appendixes D.4, D.5, E.5 and E.6, the recipient field of requests
> and the sender field of responses are specified as "the name of the
> CA". It is no problem for CA which signs the CMP response. However, as
> best practice, the CA's private key which is used to sign the
> certificates, is NOT RECOMMENDED to sign/decrypt the communication
> messages. In this case, another entity (private key + certificate) is
> used to decrypt the incoming messages and sign the outgoing ones. The
> text and comment for the fields "recipient" in requests and "sender"
> in responses need to be corrected to the case described above. If you
> think the original text and comment are correct, then we need
> instruction on how to handle this case. 

Hendrik and I see your point and agree that the CA issuer private key
should better not be used also CMP message protection by the CA.

Yet note that the formulation "the name of the CA" given in RFC 4210
does not (necessarily) imply that this is the same name as used in the
CA issuer certificate,
and even if so, the CA may have separate key pairs (and related
certificates) for these two types of activities under the same name.
So in our view RFC 4210 is not wrong here.

On the other hand, it's certainly good to point out to readers that the
CA should better not use the same key pairs (and cert) for issuing certs
and protecting CMP messages.
Therefore, we plan to address this topic more generally in the Security
Considerations section of
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates.

Does this sufficiently address your point?

    David

---

From: Lijun Liao <[email-masked]>
Date: Fri, 16 Jul 2021 15:38:12 +0200

David,

yes. Adding some text to point out this is enough for me.

Lijun

David von Oheimb <[email-masked]> schrieb am Fr., 16. Juli 2021, 14:39:

> In appendixes D.4, D.5, E.5 and E.6,
> the recipient field of requests and the sender field of responses are specified as "the name of the CA".
> It is no problem for CA which signs the CMP response.
>
>
>
> However, as best practice,
> the CA's private key which is used to sign the certificates, is NOT RECOMMENDED to sign/decrypt the communication messages.
> In this case, another entity (private key + certificate) is used to decrypt the incoming messages and sign the outgoing ones.
>
>
>
> The text and comment for the fields "recipient" in requests and "sender" in responses need to be corrected to the case described above.
> If you think the original text and comment are correct, then we need instruction on how to handle this case.
>
> Yet note that the formulation "the name of the CA" given in RFC 4210 does
> not (necessarily) imply that this is the same name as used in the CA issuer
> certificate,
> On the other hand, it's certainly good to point out to readers that the CA
> should better not use the same key pairs (and cert) for issuing certs and
> protecting CMP messages.