Re: [Netconf] PKCS7 --> CMS

[Sean Leonard <[e-mail]>]

Hi there, just catching up...
What happened to this thread?

I checked the latest draft (draft-ietf-netconf-zerotouch-22), and id-ct-zerotouchInformationXML and id-ct-zerotouchInformationJSON are not actually referenced in the main body. The text should mention specifically that they are to be used in XML and JSON circumstances. Am I missing something?

There is a related typo in zerotouch-22: the draft uses id_data throughout but it is supposed to be id-data.

Regards,

Sean

> On Feb 14, 2018, at 4:16 PM, Kent Watsen <[e-mail]> wrote:
> 
> FWIW, the ANIMA Voucher draft includes this text (note the *** part):
> 
>   Note that Section 5.1 of [RFC5652] includes a discussion about how to
>   validate a CMS object which is really a PKCS7 object (cmsVersion=1).
>   Intermediate systems (such the BRSKI Registrar) which might need to
>   evaluate the voucher in flight MUST be prepared for such an older
>   format.  ***No signaling is necessary, as the Manufacturer knows the
>   capabilities of the pledge, and will use an appropriate format
>   voucher for each pledge.***
> 
> This means that there is already a mechanism for a system to pass XML
> encoded data if need be.
> 
> My local draft has similar support in this text:
> 
>   When the bootstrapping data is unsigned, as it might be when
>   communicated over trusted channels, the CMS structure's top-most
>   content type MUST be one of the OIDs described in Section 11.3 or the
>   OID id_data (1.2.840.113549.1.7.1), in which case the encoding (JSON,
>   XML, etc.)  SHOULD be communicated externally.  In either case, the
>   associated content is an octet string containing zerotouch-
>   information data in the expected encoding.
> 
>   (and mirror-like text for the case when the bootstrapping data is signed)
> 
> I don't know, but given that the ability to send XML is already there, maybe it's better for us to be explicit and keep both "content type" registrations?
> 
> Personally, I still (relative to when I mentioned it in my email to Russ) think it best to have a generic "id-ct-YangEncodedData" for an ASN.1 structure like this:
> 
>    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 cover *all* YANG encoded data.  Imagine, doing so would mean that any YANG-encoded data artifact (yang-data?), could be fully-typed while also being:
> 
>  1) unsigned
>  2) signed
>  3) encrypted
>  4) signed and encrypted
> 
> The only thing I don't like is that it entails needing to quickly write a new I-D and get it adopted so that this draft can have a normative reference to it.  That said, it would be a *very* small draft - something like 5 pages...
> 
> Kent // contributor
> 
> 
> 
> On 2/13/18, 11:49 PM, "Mahesh Jethanandani" <[e-mail]> wrote:
> 
> 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
> 
> 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=
> 
> 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]
> 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]
> https://www.ietf.org/mailman/listinfo/netconf
> 
> Mahesh Jethanandani
> [e-mail]
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf