Re: [Netconf] PKCS7 --> CMS

[Mahesh Jethanandani <[e-mail]>]

Dear WG,

Does anyone have objection to the proposal below for the envelope information to be JSON format only, for now, with the idea that if XML support is needed, it can be added later?

Barring any objections, we want to close on this issue and send the draft for publication.

Thanks

> On Feb 12, 2018, at 10:09 AM, Kent Watsen <[e-mail]> wrote:
> 
> 
> Hi all,
> 
> Line 1704 of the commit here [1] shows both XML and JSON content types being registered.
> 
> 	id-ct-zerotouchInformationXML
> 	id-ct-zerotouchInformationJSON
> 
> 
> But the ANIMA Voucher draft only defines a single content type for JSON.  Their rational for supporting just one was that it would promote interoperability, though XML support could be added at any time.
> 
> But having one artifact (zerotouch-information) support two encodings while the other (ownership-voucher) can only support one doesn't seem helpful either.  What to do?
> 
> To be clear, this decision has no impact on if the bootstrap server supports XML or JSON, or even what the bootstrapping device's NETCONF/RESTCONF protocols support.  But it does mean that, in the worst case, a native-XML server may need to process a JSON document during the bootstrapping process.
> 
> [1] https://github.com/netconf-wg/zero-touch/commit/3d938e4d539407c8bb2b4e162dca497b01d8315c#diff-ac14b4845b3be918b874f2d3564d5d09R1704 <https://github.com/netconf-wg/zero-touch/commit/3d938e4d539407c8bb2b4e162dca497b01d8315c#diff-ac14b4845b3be918b874f2d3564d5d09R1704>
> 
> Thoughts?  - should we again go back to only supporting JSON?   - or should we go ahead and define both now, with the assumption and the ownership voucher will someday support XML too?
> 
> Kent // contributor
> 
> 
> 
> [moving Russ to BCC]
> 
> All,
> 
> The PKCS7 --> CMS change is reflected here:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_zero-2Dtouch_commit_3d938e4d539407c8bb2b4e162dca497b01d8315c&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A-qDS0CYdeZjFh3qD4jW4CyOwFIr_KmezgiLDovTZbw&s=YcPdTFTtK-LwGeIHtUMmazXzme-WkaIpGzibJMVdVHQ&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_zero-2Dtouch_commit_3d938e4d539407c8bb2b4e162dca497b01d8315c&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A-qDS0CYdeZjFh3qD4jW4CyOwFIr_KmezgiLDovTZbw&s=YcPdTFTtK-LwGeIHtUMmazXzme-WkaIpGzibJMVdVHQ&e=>
> 
> I plan to automatically merge this branch into -20, as already the shepherd asked for this update.
> 
> Kent // author
> 
> 
> 
> ===== original message=====
> 
> I think that defining the two content types would be better.  If you use id-data, then you need another way to figure out what content type is embedded.
> 
> Russ
> 
> 
>> On Feb 6, 2018, at 8:44 PM, Kent Watsen <[e-mail]> wrote:
>> 
>> Hi Russ,
>> 
>> Drilling down a little, I can imagine us defining a couple content types:
>> 
>> 	id-ct-zerotouchInformationXML
>> 	id-ct-zerotouchInformationJSON
>> 
>> But, in both cases, the "content" would be just an octet string (i.e.,
>> an XML or JSON encoded document).  In particular, we would not define
>> an ASN.1 structure to represent the "zerotouch information" structure.
>> 
>> Is defining two types such as above the expectation or, since it's
>> just an octet string, perhaps we should use "id-data"?  RFC 5652
>> section 4 says this about the 'data' type (I added the quotes):
>> 
>>  "The 'data' content type is intended to refer to arbitrary octet
>>  strings, such as ASCII text files; the interpretation is left to the
>>  application.  Such strings need not have any internal structure
>>  (although they could have their own ASN.1 definition or other
>>  structure)."
>> 
>> Or, do you think we should look to do something even more generic,
>> such as:
>> 
>> 	id-ct-YangEncodedData
>> 
>>     YangEncodedData {
>>       moduleName           string        // e.g., "ietf-zerotouch-information"
>>       moduleRevision       string        // e.g., "2017-12-09"
>>       encoding             enum          // XML, JSON, etc.
>>       data                 octet string  // the YANG-encoded data
>>     }
>> 
>> Which would allow for the brokering of any YANG data.  Such a type 
>> could've, for instance, also been used by the ANIMA voucher draft.
>> 
>> Thoughts?  - anyone?
>> 
>> Kent
>> 
>> 
>> 
>> ===== original message =====
>> 
>> Kent:
>> 
>> Yes.  This is the approach takes for signed firmware packages in RFC 4108.
>> 
>> Russ
>> 
>> 
>>> On Feb 6, 2018, at 3:40 PM, Kent Watsen <[e-mail]> wrote:
>>> 
>>> Russ,
>>> 
>>> I like it.  I didn't know that it was possible to set the top-level content
>>> type value like that.  Is the net-result still considered a CMS structure?
>>> 
>>> Thanks,
>>> Kent
>>> 
>>> 
>>> ===== original message =====
>>> 
>>> I suggest that ContentInfo is always present, then for the signed case:
>>> 
>>>    ContentInfo {
>>>      contentType          id-signedData, -- (1.2.840.113549.1.7.2)
>>>      content              SignedData
>>>    }
>>> 
>>>    SignedData {
>>>      version              CMSVersion, -- always set to 3
>>>      digestAlgorithms     DigestAlgorithmIdentifiers, -- Only one
>>>      encapContentInfo     EncapsulatedContentInfo,
>>>      certificates         CertificateSet, -- Signer cert. path
>>>      crls                 CertificateRevocationLists, -- Optional
>>>      signerInfos          SET OF SignerInfo -- Only one
>>>    }
>>> 
>>>    SignerInfo {
>>>      version              CMSVersion, -- always set to 3
>>>      sid                  SignerIdentifier,
>>>      digestAlgorithm      DigestAlgorithmIdentifier,
>>>      signedAttrs          SignedAttributes, -- Required
>>>      signatureAlgorithm   SignatureAlgorithmIdentifier,
>>>      signature            SignatureValue,
>>>      unsignedAttrs        UnsignedAttributes -- Optional
>>>    }
>>> 
>>>    EncapsulatedContentInfo {
>>>      eContentType         <your-netconf-content-type>
>>>      eContent             OCTET STRING
>>>    }                            -- Contains the content
>>> 
>>> The unsigned case:
>>> 
>>>    ContentInfo {
>>>      contentType          <your-netconf-content-type>
>>>      content              -- Contains the content
>>>    }
>>> 
>>> Russ
>>> 
>>> 
>>>> On Feb 6, 2018, at 11:53 AM, Kent Watsen <[e-mail]> wrote:
>>>> 
>>>> Hi Russ,
>>>> 
>>>> I'm looking into switching from PKCS7 to CMS change in the NETCONF
>>>> zerotouch draft.  This update would be similar to the change to the
>>>> ANIMA voucher draft.  However, I noticed that RFC 5652 says in 
>>>> Section 5.2:
>>>> 
>>>> "In the degenerate case where there are no signers, the
>>>> EncapsulatedContentInfo value being "signed" is irrelevant.  In this
>>>> case, the content type within the EncapsulatedContentInfo value being
>>>> "signed" MUST be id-data (as defined in Section 4), and the content
>>>> field of the EncapsulatedContentInfo value MUST be omitted."
>>>> 
>>>> Note, this text is similar to the last paragraph in RFC 2315 Section 
>>>> 9.1, though there it is just a "recommendation" that the value be
>>>> omitted.
>>>> 
>>>> This is a problem for the NETCONF zerotouch draft, where we currently
>>>> have a PKCS7 object that is sometimes signed.  We choose this approach
>>>> because then, in all cases, a PKCS7 object is being communicated.  But
>>>> it's no longer allowed in CMS?
>>>> 
>>>> Questions:
>>>> 
>>>> 1) Can the zerotouch draft explicitly allow the "eContent" field 
>>>> again for the degenerate case?
>>>> 
>>>> 2) If having a eContent value for the degenerate case is no longer
>>>> allowed, can we use it as grounds for not migrating to CMS?
>>>> 
>>>> 3) Are there any other generic "envelop" structure that can be 
>>>> "sometimes signed"?
>>>> 
>>>> 
>>>> Thanks,
>>>> Kent
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A-qDS0CYdeZjFh3qD4jW4CyOwFIr_KmezgiLDovTZbw&s=o18ndrwnbD62ZZH5zVUoH7nk1Y0SPkdaxROvPs3_wrc&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A-qDS0CYdeZjFh3qD4jW4CyOwFIr_KmezgiLDovTZbw&s=o18ndrwnbD62ZZH5zVUoH7nk1Y0SPkdaxROvPs3_wrc&e=>
> 
> 
> _______________________________________________
> Netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh Jethanandani
[e-mail]