Re: [Netconf] PKCS7 --> CMS

[Kent Watsen <[e-mail]>]

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]