Re: [Netconf] PKCS7 --> CMS
Kent Watsen <kwatsen@juniper.net> Sat, 10 February 2018 04:17 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 D5AF6126D85 for <netconf@ietfa.amsl.com>; Fri, 9 Feb 2018 20:17:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.194
X-Spam-Level:
X-Spam-Status: No, score=-1.194 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, SUBJ_ALL_CAPS=1.506, URIBL_BLOCKED=0.001] autolearn=no 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 h1T4pBxZPCVG for <netconf@ietfa.amsl.com>; Fri, 9 Feb 2018 20:17: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 42020126C26 for <netconf@ietf.org>; Fri, 9 Feb 2018 20:17: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 w1A4E5YR025023 for <netconf@ietf.org>; Fri, 9 Feb 2018 20:16:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=R6buLAfHiVMgunX+fEhGZbSF0KZ9en9Nf2onE7Vb8dg=; b=eY3KGtv5oFd+yH5qnctQ97Xjq9hGctTydj8hmArNb9nYDnRqW84792vJ7ul0s/cIJtLV 8eu3K+dg+WW2S0K8EwCbGh1TEAggtn2vnMJlb5nJihhdQIGRQHELh3jJkY0jOq2G+6ZN M+cH6YW0RO6VHYbI8ODwJ+ShHE4df3P1o8rE8sgPYZiBR+rt3di2aqkTtLUer11LLTnK D4YHhHNGj+IPWaklV3TY+XjvesmtSykb581d2UeXsCp/nmOZvXuCGBbWBxlSL3gfhlm0 nKe2Mq4yRoTXb49ypedNHGItfUIX/F2M/uJ8AlUVwXDMgPdx5LDkWS3DWxB75kNXyXif QQ==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0177.outbound.protection.outlook.com [216.32.180.177]) by mx0a-00273201.pphosted.com with ESMTP id 2g1scmg0ab-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <netconf@ietf.org>; Fri, 09 Feb 2018 20:16:59 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3497.namprd05.prod.outlook.com (10.174.242.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Sat, 10 Feb 2018 04:16:57 +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.007; Sat, 10 Feb 2018 04:16:57 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: PKCS7 --> CMS
Thread-Index: AQHTn2r+sWuRsc2AIUqmrIh1BY2swKOXpbyA///c+YCAAFWlgP///4CAgAEZRICAA8gzAA==
Date: Sat, 10 Feb 2018 04:16:57 +0000
Message-ID: <9DC65AB8-C5B9-4413-BC2D-923F0480D8D7@juniper.net>
References: <8616F4BC-65CE-4187-8135-C5DF4C83D924@juniper.net> <DD343969-332F-46AF-8637-3D5B757B5EB1@vigilsec.com> <939B57F5-C38D-4E95-BDC1-FC01FA06DB97@juniper.net> <46D20605-3B0A-4BA9-8186-625D0FDB9D30@vigilsec.com> <DD42F58C-DC7D-4414-9CE0-6DEA26DC06EA@juniper.net> <0136053C-DE4C-4588-A06F-0AE1A29BC83D@vigilsec.com>
In-Reply-To: <0136053C-DE4C-4588-A06F-0AE1A29BC83D@vigilsec.com>
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.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3497; 7:G8evIIiFsq9oGdlTW0i81xjQ/zAXL+8UZqnVv2PxbWV+DbNqTWj0hF24iZ7O8/ib19hQHIoR/t9lEpxScEi5GSn42tLZbYxgpWIlHuSeNjp3Qc7C/Gb4FsIh9FoRVHZUl0UizludMvSnpkPysvBkxXo1awA/JKM44ho0JY0goT8+gr/waJoMf5LWAXCYaq7Xl9bcfga3rimkuxJhg9izmSj280qj0rZ9mIjXfHIUkzWsIKJhsw2xGgT8IbKdSDxQ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 33c186ac-87f5-4bef-dff1-08d5703d1fd8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3497;
x-ms-traffictypediagnostic: DM5PR05MB3497:
x-microsoft-antispam-prvs: <DM5PR05MB34976827280B42AA09F94F53A5F10@DM5PR05MB3497.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(6055026)(6041288)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB3497; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3497;
x-forefront-prvs: 057906460E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(396003)(366004)(376002)(39380400002)(51444003)(377424004)(199004)(189003)(3280700002)(66066001)(2501003)(58126008)(6116002)(1730700003)(2950100002)(316002)(5250100002)(59450400001)(25786009)(6916009)(229853002)(83716003)(305945005)(8676002)(7736002)(3846002)(81156014)(5660300001)(53936002)(86362001)(99286004)(2900100001)(3660700001)(6512007)(2906002)(6246003)(6306002)(76176011)(93886005)(82746002)(33656002)(36756003)(2351001)(105586002)(6506007)(26005)(6486002)(186003)(97736004)(81166006)(53546011)(8936002)(83506002)(478600001)(6436002)(14454004)(966005)(5640700003)(102836004)(106356001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3497; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: RK9TV4L+o03SVblqSw3iXNX5fFMBxqtRRpOKgVlc+cEtV4g6pdxd00/u3u2pbHdJDjeuiuufngliR/+l+duOcg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D992002C0DE4504996D21159D8337426@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 33c186ac-87f5-4bef-dff1-08d5703d1fd8
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2018 04:16:57.1790 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3497
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-10_01:, , 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=1011 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-1802100053
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/y7663AabJfEflJ2IYRWsSgPKP5w>
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: Sat, 10 Feb 2018 04:17:03 -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===== 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] PKCS7 --> CMS Kent Watsen
- Re: [Netconf] PKCS7 --> CMS Russ Housley
- Re: [Netconf] PKCS7 --> CMS Kent Watsen
- Re: [Netconf] PKCS7 --> CMS Russ Housley
- Re: [Netconf] PKCS7 --> CMS Kent Watsen
- Re: [Netconf] PKCS7 --> CMS Russ Housley
- Re: [Netconf] PKCS7 --> CMS Kent Watsen
- Re: [Netconf] PKCS7 --> CMS Kent Watsen
- Re: [Netconf] PKCS7 --> CMS Mahesh Jethanandani
- Re: [Netconf] PKCS7 --> CMS Kent Watsen
- Re: [Netconf] PKCS7 --> CMS Sean Leonard
- Re: [Netconf] PKCS7 --> CMS Kent Watsen
- Re: [Netconf] PKCS7 --> CMS Sean Leonard