Re: [Netconf] PKCS7 --> CMS

Kent Watsen <kwatsen@juniper.net> Mon, 12 February 2018 18:10 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5854D1201F2 for <netconf@ietfa.amsl.com>; Mon, 12 Feb 2018 10:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqWAHI-3aOmZ for <netconf@ietfa.amsl.com>; Mon, 12 Feb 2018 10:10:01 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DC412D7EC for <netconf@ietf.org>; Mon, 12 Feb 2018 10:10:01 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1CI8hrC002395 for <netconf@ietf.org>; Mon, 12 Feb 2018 10:10:01 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=vv3jjK3EFUWPHHQW1okeWHFe67YE2wcA4/LgITuy7SE=; b=euTl7U5oiroh99O8paOhJPIEvzz3SUTiWm6DqbnkCu2GONPoEFPmgxCRCWhsOmZKw4TB wbWdQ1szvVhACdJR3BtTF6ZWu6eHZwNDx6LXFYR+zGWeAOHe3sq3+C5L4It+ZysOLPok NqYpaub5rlX2nyOaOJjleEInEj8xcnd1HVJZ9XO/CyHH9jv+59ysAXLsfToR/zScYCDs GCWLT+ao6ju4yiharBNS1pZ1P2lZcYvr8IguuBRrjXHpXc5eF+bDD/1I/mZCS40pECTK gkReZkuX0XZaYm701Lh2+RUv4U+nJTcxwD3BosCUBferVs9SKuqxpUct5et/I1drmHjf ww==
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) by mx0a-00273201.pphosted.com with ESMTP id 2g39150rpc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <netconf@ietf.org>; Mon, 12 Feb 2018 10:10:00 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3532.namprd05.prod.outlook.com (10.174.242.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 18:09:59 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.013; Mon, 12 Feb 2018 18:09:59 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] PKCS7 --> CMS
Thread-Index: AQHTpCyx8yqBhSZxuEy4tdotbWzQvw==
Date: Mon, 12 Feb 2018 18:09:58 +0000
Message-ID: <D00C0834-397B-47B8-9868-54D5F6E64E20@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3532; 7:uzLXQUr73alH86akaFTNSjQoEJXueFyCafzNl0fi6yAbkm1nJKV8LdqYdGQsNi1lz0NzGoXl6a4NpC9Hoy7+wX/lr8vMXOD7o+o5dHDKRm3qBki/CMTFTHVd0fn7U9KuQ5UxOdFUcHKAk6fpK/zcP1UfXptf4dtrg8hbzxHrgCOVDOg3i+Es9a4xT8cVWVGwVFPzBpCLtwkNl0yHEXFRd50d6Wcc0vTC8lSOs/MvX9K6K6lJchF7cMvXtgfRJEV2
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 22962731-965c-4665-8650-08d57243d421
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3532;
x-ms-traffictypediagnostic: DM5PR05MB3532:
x-microsoft-antispam-prvs: <DM5PR05MB35320BAA53A8524AB46B67C9A5F70@DM5PR05MB3532.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(10436049006162)(166708455590820)(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231101)(944501161)(10201501046)(6055026)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB3532; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3532;
x-forefront-prvs: 0581B5AB35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(366004)(346002)(396003)(39860400002)(189003)(199004)(53754006)(377424004)(51444003)(97736004)(6346003)(59450400001)(6506007)(53546011)(3280700002)(102836004)(26005)(2906002)(68736007)(229853002)(186003)(83716003)(25786009)(1730700003)(81166006)(81156014)(8676002)(5250100002)(86362001)(575784001)(2900100001)(2501003)(8936002)(305945005)(5660300001)(105586002)(33656002)(106356001)(36756003)(82746002)(66066001)(316002)(6116002)(3846002)(5640700003)(83506002)(2351001)(6306002)(6436002)(58126008)(53936002)(6916009)(6486002)(99286004)(478600001)(3660700001)(966005)(6246003)(14454004)(7736002)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3532; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: WYRnL9g1nokVlH/qn6hEk1HQN57KsJyXrGB52/d8HUeMFQILntMd+Q8mrVssee3s39mUJF2KQejVgVXFyg6LwA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <BE851ACB30C9634F8AC294FBF395302F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 22962731-965c-4665-8650-08d57243d421
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 18:09:58.9464 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3532
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-12_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802120233
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/IcHl5lZ0EFkp13EsxCOEzp7weS8>
Subject: Re: [Netconf] PKCS7 --> CMS
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Feb 2018 18:10:03 -0000

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 <kwatsen@juniper.net> 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 <kwatsen@juniper.net> 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 <kwatsen@juniper.net> 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
Netconf@ietf.org
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=