Subject: [Netconf] PKCS7 --> CMS

From: Kent Watsen <[email-masked]>
Date: Tue, 6 Feb 2018 16:53:21 +0000

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Feb 2018 12:45:33 -0500

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 <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 6 Feb 2018 20:40:11 +0000

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 =====

      ContentInfo {

      SignedData {

      SignerInfo {

The unsigned case:

      ContentInfo {

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Feb 2018 15:46:43 -0500

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 <[email-masked]> wrote:
> 
> Russ,
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Feb 2018 01:44:55 +0000

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

Kent:

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 7 Feb 2018 08:31:37 -0500

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 <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: Kent Watsen <[email-masked]>
Date: Sat, 10 Feb 2018 04:16:57 +0000

[moving Russ to BCC]

All,

The PKCS7 --> CMS change is reflected here:

https://github.com/netconf-wg/zero-touch/commit/3d938e4d539407c8bb2b4e162dca497b01d8315c

I plan to automatically merge this branch into -20, as already the shepherd asked for this update.

Kent // author

===== original message=====

Russ