IETF Logo Mail Archive

Re: [netconf] crypto-types fallback strategy

Wang Haiguang <wang.haiguang.shieldlab@huawei.com> Mon, 07 October 2019 08:30 UTC

Return-Path: <wang.haiguang.shieldlab@huawei.com>
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 48C00120020 for <netconf@ietfa.amsl.com>; Mon, 7 Oct 2019 01:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.1
X-Spam-Level:
X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KbDmXun1fBlI for <netconf@ietfa.amsl.com>; Mon, 7 Oct 2019 01:30:07 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A304D1207FE for <netconf@ietf.org>; Mon, 7 Oct 2019 01:30:07 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 936D7A6BAC1A8D93DD01; Mon, 7 Oct 2019 09:30:04 +0100 (IST)
Received: from sineml703-chm.china.huawei.com (10.223.161.110) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Oct 2019 09:30:04 +0100
Received: from sineml706-chm.china.huawei.com (10.223.161.113) by sineml703-chm.china.huawei.com (10.223.161.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 7 Oct 2019 16:30:02 +0800
Received: from sineml706-chm.china.huawei.com ([10.223.161.113]) by sineml706-chm.china.huawei.com ([10.223.161.113]) with mapi id 15.01.1713.004; Mon, 7 Oct 2019 16:30:02 +0800
From: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>
To: "Salz, Rich" <rsalz@akamai.com>, Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Thread-Topic: [netconf] crypto-types fallback strategy
Thread-Index: AQHVaNykQ+AWDonnw0K18K8BnfwgSqcoyBWAgAU9agCAASLxgIAAPqgAgAAEIYCAACwMAIAAA3qAgAACEwCAARRSgIAAM8kAgAABGICAABougIAABpcAgAAikgCAAANggIAd04nA
Date: Mon, 07 Oct 2019 08:30:02 +0000
Message-ID: <1c08a27c27ea4177b9cfc524c92042f0@huawei.com>
References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30@MN2PR11MB4366.namprd11.prod.outlook.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <MN2PR11MB4366F63419F6BD4EF106766FB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <MN2PR11MB43669B3A47A39FD93B47292FB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <MN2PR11MB4366B5C09B4348FDAE33E2BCB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <MN2PR11MB4366F20EE2FD6DF04B965125B58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <EBE4757D-E99E-41EB-A52B-A25F023BF4BC@akamai.com> <MN2PR11MB4366E4ECE10DFB018941BA5FB58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <2614C1E8-A015-4816-AA3B-F75D02F5701C@akamai.com> <0100016d45447f68-68073ae2-3f96-4c6d-846d-7c661c1cdb0c-000000@email.amazonses.com> <7AE47512-8974-4A8C-9756-699CAE220EF9@akamai.com>
In-Reply-To: <7AE47512-8974-4A8C-9756-699CAE220EF9@akamai.com>
Accept-Language: en-SG, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.215.37.205]
Content-Type: multipart/alternative; boundary="_000_1c08a27c27ea4177b9cfc524c92042f0huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9fk93pXaGlCErRVUrgwN3Fdsu_g>
Subject: Re: [netconf] crypto-types fallback strategy
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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, 07 Oct 2019 08:30:11 -0000

Sorry to bring you all back to an email two weeks ago.

If I am not wrong, TLS 1.3 support to use raw public key between client and server.
I think TLS + Raw public key has been specified in RFC 7250 and later merge in RFC 8446 (TLS 1.3)

Best regards.

Haiguang

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Salz, Rich
Sent: Thursday, September 19, 2019 12:58 AM
To: Kent Watsen <kent+ietf@watsen.net>
Cc: netconf@ietf.org; Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Subject: Re: [netconf] crypto-types fallback strategy


Ø  The desire to use SubjectPublicKeyInfo is per tests (2) and (4) described here: https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_netconf_ysukDdbCA0a70heF1a-5FldZNr4yE&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=2WjGA7HZCdgO3PuNIGcShf2is7JW06LCQdbjHnYFNs8&s=2a467Qepi3ZnOMc6bomXjp3ysTseF0EUXytuahNHZNw&e=>.

Those experiments do not matter.  TLS sends X509 certificates.  I am not aware of any protocol (and I don’t know all of them, of course) that sends raw public keys.  What protocols are you thinking of?

If you want to configure an HTTPS server using netconf/yang, you will need to give that server X509 certificates.


> don't understand the question.  I think your tip-toeing on a concern that a key should only be encrypted with a certain other key, if only the ensure that the strength of the encrypting key is not less than the key being encrypted.  Is this what you mean?

No, I was asking if “encrypted private key” is a separate thing from “plaintext private key.”

v2.23.0 | Report a Bug | By Email