Re: [Netconf] PKCS7 --> CMS

[Kent Watsen <[e-mail]>]

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