Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.txt

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 15 Oct 2021 10:05:02 +0000

Hi Kent, David,

I just wanted to check whether there was any final resolution on this before I send this doc on to IETF LC?

For my opinion:

  *   I don’t have a particularly strong opinion for MUST vs must, so happy to leave that to the author’s discretion.
  *   I agree that adding a separate Verifying Proof of Origin section makes sense.

Regards,
Rob

From: Kent Watsen <[email-masked]>
Sent: 30 August 2021 16:58
To: David von Oheimb <[email-masked]>
Cc: Rob Wilton (rwilton) <[email-masked]>; [email-masked]; [email-masked]; Brockhaus, Hendrik <[email-masked]>
Subject: Re: New Version Notification for draft-ietf-netconf-sztp-csr-06.txt

Hi David,

Hi Kent,
thanks for your update and providing the diff.
I had a closer look at sections 4.1.5 and 4.2.1 and found some further issues.

  *   Section 4.1.5 - since correct identity of the request origin is crucial for any type of identity cert generation:
old:
A The CSR's origin SHOULD be verified before a certificate is issued.
new:
The origin of the CSR MUST be verified before a certificate is issued.

Ack.

Perhaps replace “MUST” with “must”, since the behavior is normatively defined by other documents?

  *   Section 4.2.1 - actually, a proof-of-possession can and should be done in all addressed situations,
while for PKCS#10 it is hard to link this to a proof-of-origin.
old:
When the bootstrapping device's manufacturer-generated private key
 (e.g., the IDevID key) is reused for the CSR, proof-of-possession is
verified by ensuring the CSR was signed by that key.

When a new asymmetric key is used, proof-of-possession may be
verified, with the CMP or CMC formats, by ensuring the parent ASN.1
structure containing the CSR is signed by the manufacturer-generated key.
new:
Since the CSR should have been self-signed using the private key
corresponding to the public key placed in the CSR, the proof-of-possession
can be checked by verifying this signature using the included public key.
With the CMP or CMC formats, this proof-of-origin is directly linked to the
proof-or-origin provided by the parent ASN.1 structure, which contains
origin authentication using the manufacturer-generated private key or using
the shared secret.

The current section is titled "Verifying Proof of Possession”.  I think that new “proof of origin" text should go into a new section called "Verifying Proof of Origin”.  Something like this:

            Verifying Proof of Possession

            Regardless if using a new asymmetric key or the bootstrapping
            device's manufacturer-generated key (e.g., the IDevID key), the
            public key is placed in the CSR and the CSR is signed by that
            private key.  Proof-of-possession of the private key is verified
            by ensuring the signature over the CSR using the public key
            placed in the CSR.

            Verifying Proof of Origin

            When the bootstrapping device's manufacturer-generated
            private key (e.g., the IDevID key) is reused for the CSR,
            proof-of-origin is verified by ensuring the CSR was signed
            by that key.

            When a new asymmetric key is used, proof-or-origin is
            provided, in the CMP and CMC formats, by the CSR’s
            parent ASN.1 structure containing origin authentication
            using either the manufacturer-generated private key or
            a shared secret.

Thoughts?

K.

---

From: David von Oheimb <[email-masked]>
Date: Fri, 15 Oct 2021 13:26:20 +0200

Hi all,

thanks Rob for bringing this up again - it turns out that I missed 
Kent's response and thus did not answer yet - sorry for that!

  * Hendrik and I also do not have a strong opinion on 'MUST' vs. 'must'.
    Yet I agree with Kent to likely better use 'must' because the
    normative requirement anyway should be given elsewhere.
  * We agree that it is better to add a separate section
    "Verifying Proof of Origin"
  * We agree on the text as adapted by Kent of the section "Verifying
    Proof of Possession".
  * Regarding the proposed new text of the section "Verifying Proof of

> proof-of-origin is verified by ensuring the CSR was signed
Hmm, this proof of origin only works if the IDevID has already been 
authenticated before by the entity performing the proof - is this the case?

Concerning the 2nd part of the new section,
I found that the text I proposed on Aug 30th unfortunately contained a 
critical mistake - it should have read:

     With the CMP or CMC formats, *the proof-of-possession* is directly 
linked to the
     proof-or-origin provided by the parent ASN.1 structure, which contains
     origin authentication using the manufacturer-generated private key 
or using
     the shared secret.

> using either the manufacturer-generated private key or

This text loses the link between POP and POO that I was aiming to point 
out with my earlier text.
Therefore, I propose a further adaptation of this part, as follows:

     When a new asymmetric key is used with the CMP or CMC formats, the 
parent ASN.1 structure of the CSR
     provides origin authentication using either the 
manufacturer-generated private key or shared secret.
     In this way the proof-of-possession of the CSR is directly linked 
to the proof-or-origin provided by the parent ASN.1 structure.

David

On 15.10.21 12:05, Rob Wilton (rwilton) wrote:
>   * I don’t have a particularly strong opinion for MUST vs must, so
>     happy to leave that to the author’s discretion.
> *From:*Kent Watsen <[email-masked]>
> *Sent:* 30 August 2021 16:58
> *To:* David von Oheimb <[email-masked]>
> *Cc:* Rob Wilton (rwilton) <[email-masked]>; [email-masked]; 
> [email-masked]; Brockhaus, Hendrik 
> <[email-masked]>
> *Subject:* Re: New Version Notification for 
> draft-ietf-netconf-sztp-csr-06.txt
>
> Hi David,
>
>     Hi Kent,
>
>       * Section 4.1.5 - since correct identity of the request origin
>         is *crucial* for any type of identity cert generation:
>
>     old:
>
> The current section is titled "Verifying Proof of Possession”. I think 
> that new “proof of origin" text should go into a new section called 
> "Verifying Proof of Origin”.  Something like this:
>
>
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 Oct 2021 21:41:41 +0000

Hi David and Rob,

Comments below.

Updated draft here: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-09 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-09>

PS: a -09/-08 diff shows a tree-diagram changed, but it’s only me switching from using `yanglint` to `pyang` to generate it, the `pyang` reordered the things a little, but it's materially the same.

K.

> On Oct 15, 2021, at 7:26 AM, David von Oheimb <[email-masked]> wrote:
> 
> Hi all,
> 
> thanks Rob for bringing this up again - it turns out that I missed Kent's response and thus did not answer yet - sorry for that!
> 
> Hendrik and I also do not have a strong opinion on 'MUST' vs. 'must'.
> Yet I agree with Kent to likely better use 'must' because the normative requirement anyway should be given elsewhere.

It is now ‘must’.

> We agree that it is better to add a separate section "Verifying Proof of Origin"

Noted (more below)
> We agree on the text as adapted by Kent of the section "Verifying Proof of Possession".

Done.

> Regarding the proposed new text of the section "Verifying Proof of Origin":
> 
>> 
> Hmm, this proof of origin only works if the IDevID has already been authenticated before by the entity performing the proof - is this the case?

Yes.  First validate the IDevID (which is readily available) using the IDevID-issuer cert, then ensure the public key in the CSR is the same as the public key in the IDevID.

Please OLD/NEW text for how you would like to see it improved.

> I found that the text I proposed on Aug 30th unfortunately contained a critical mistake - it should have read:
> 
>     With the CMP or CMC formats, the proof-of-possession is directly linked to the
> This text loses the link between POP and POO that I was aiming to point out with my earlier text.
>     When a new asymmetric key is used with the CMP or CMC formats, the parent ASN.1 structure of the CSR 
>     provides origin authentication using either the manufacturer-generated private key or shared secret.
>     In this way the proof-of-possession of the CSR is directly linked to the proof-or-origin provided by the parent ASN.1 structure.
> 

Incorporated.  But I added a missing comma and a missing article (‘a’).

Kent

>> I don’t have a particularly strong opinion for MUST vs must, so happy to leave that to the author’s discretion.
>> I agree that adding a separate Verifying Proof of Origin section makes sense.
>>  
>> Regards,
>> Rob
>>  
>>  
>> From: Kent Watsen <[email-masked]> <mailto:[email-masked]> 
>> To: David von Oheimb <[email-masked]> <mailto:[email-masked]>
>> Cc: Rob Wilton (rwilton) <[email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Brockhaus, Hendrik <[email-masked]> <mailto:[email-masked]>
>> Section 4.1.5 - since correct identity of the request origin is crucial for any type of identity cert generation:
>> old:
>> Section 4.2.1 - actually, a proof-of-possession can and should be done in all addressed situations,

---

From: David von Oheimb <[email-masked]>
Date: Mon, 25 Oct 2021 12:42:33 +0200

Hi Kent et al.,

On 10/22/21 23:41, Kent Watsen wrote:
>
> Updated draft here: 
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-09 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-09&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C7cf0a08cc6ce4902079b08d995a4bcfd%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637705357503318223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yKWfmyGEIfsit6l5wqzISdO9%2Fqk31PsR1Zs5D5ISEic%3D&reserved=0>
>
thanks for your answer and new version 09.

>>   * Regarding the proposed new text of the section "Verifying Proof
>>     of Origin":
>>
>>>
> Yes.  First validate the IDevID (which is readily available) using the 
> IDevID-issuer cert, then ensure the public key in the CSR is the same 
> as the public key in the IDevID.
I see - so in this case the IDevID has already been enrolled before and 
can be used for authentication.
Since the details are crucial but rather implicit at this point, it 
would be good to state them clearly.

> Please OLD/NEW text for how you would like to see it improved.
OLD:

NEW:

When the bootstrapping device's manufacturer-generated
private key (e.g., the IDevID key) is reused for the CSR,
proof-of-origin is verified by validating the IDevID-issuer cert
             and ensuring that the CSR uses the same key pair.

>> [...]
Thanks.
Yet you forgot to remove the OLD text, just before that new paragraph:

    When a new asymmetric key is used, proof-or-origin is provided, in
    the CMP and CMC formats, by the CSR's parent ASN.1 structure
    containing origin authentication using either the manufacturer-
    generated private key or a shared secret.

Pleased to note that you added in version version 06 a "Contributors" 
section saying:

    Special thanks goes to David von Oheimb and Hendrik Brockhaus for
    helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes.

Cheers,

     David

---

From: Kent Watsen <[email-masked]>
Date: Thu, 28 Oct 2021 23:50:04 +0000

Hi David,

Thank you for your valuable comments.  Please find the updated draft here:

	https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-10 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-10>

And the diff here:

	https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-10 <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-10>

Can you confirm is all your concerns have been addressed?

Thanks,
Kent

> On Oct 25, 2021, at 6:42 AM, David von Oheimb <[email-masked]> wrote:
> 
> Hi Kent et al.,
> 
>> Updated draft here: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-09 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-09&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C7cf0a08cc6ce4902079b08d995a4bcfd%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637705357503318223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yKWfmyGEIfsit6l5wqzISdO9%2Fqk31PsR1Zs5D5ISEic%3D&reserved=0>
>> 
> I see - so in this case the IDevID has already been enrolled before and can be used for authentication.
> Since the details are crucial but rather implicit at this point, it would be good to state them clearly.
> 
> Pleased to note that you added in version version 06 a "Contributors" section saying:
>