Re: [Netconf] PKCS7 --> CMS

[Russ Housley <[e-mail]>]

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