Subject: Re: [netconf] Adaptations for draft-ietf-netconf-sztp-csr-09.txt

From: David von Oheimb <[email-masked]>
Date: Wed, 3 Nov 2021 13:49:26 +0100

Hi Kent,

thanks for your update.

The change to section 4.2.1 is fine,
but section 4.2.2 still contains:

>     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.
which should be removed.
(The following paragraph, starting with the same words, is an improved 
version of it).

Regards,

     David

On 29.10.21 01:50, Kent Watsen wrote:
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-10&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7Ce483c97f28d243995fc208d99a6daaec%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637710618847201664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uEDe6HExKC%2FAonHRRGqaYyCtHgA5mQJo7ut4lzIYbeM%3D&reserved=0>
>
> And the diff here:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-10 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-netconf-sztp-csr-10&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7Ce483c97f28d243995fc208d99a6daaec%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637710618847201664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8101Jx9Xgsd1EYZ8fbh%2BEN4eamDa2ppZWD7rJ9PBrE8%3D&reserved=0>
>
> 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.,
>>
>> 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%7Ce483c97f28d243995fc208d99a6daaec%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637710618847211615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=k8zIqeXZ%2FRnsvB7dc7M8qnjhkL8S%2FTN%2FwU9MHetGDgU%3D&reserved=0>
>>>
>> thanks for your answer and new version 09.
>>
>>
>>>>   * Regarding the proposed new text of the section "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.
>>>>>
>>>> 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.
>> 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:
>>
>> 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.
>>
>> 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.
>>
>>
>>
>>>
>>>> Concerning the 2nd part of the new section,
>>>> [...]
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> Incorporated.  But I added a missing comma and a missing article (‘a’).
>> 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: Mon, 8 Nov 2021 13:45:52 +0000

Hi David,

Thanks for catching that.  The just-submitted -11 removes that paragraph.

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

Cheers,
Kent

> On Nov 3, 2021, at 8:49 AM, David von Oheimb <[email-masked]> wrote:
> 
> Hi Kent,
> 
> thanks for your update.
> 
> (The following paragraph, starting with the same words, is an improved version of it).
> 
> Regards,
> 
>     David
> 
> 
> 
>> 	https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-10 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-10&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7Ce483c97f28d243995fc208d99a6daaec%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637710618847201664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uEDe6HExKC%2FAonHRRGqaYyCtHgA5mQJo7ut4lzIYbeM%3D&reserved=0>
>> 
>> And the diff here:
>> 
>> 	https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-10 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-netconf-sztp-csr-10&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7Ce483c97f28d243995fc208d99a6daaec%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637710618847201664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8101Jx9Xgsd1EYZ8fbh%2BEN4eamDa2ppZWD7rJ9PBrE8%3D&reserved=0>
>> 
>>> On Oct 25, 2021, at 6:42 AM, David von Oheimb <[email-masked] <mailto:[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%7Ce483c97f28d243995fc208d99a6daaec%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637710618847211615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=k8zIqeXZ%2FRnsvB7dc7M8qnjhkL8S%2FTN%2FwU9MHetGDgU%3D&reserved=0>
>>>> 
>>>>> 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.
>>> 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.
>>> 
>>>>> 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.
>>>>> 
>>>> 
>>> Pleased to note that you added in version version 06 a "Contributors" section saying:
>>>