Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04: (with COMMENT)

"Borchert, Oliver (Fed)" <oliver.borchert@nist.gov> Wed, 10 April 2019 19:40 UTC

Return-Path: <oliver.borchert@nist.gov>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFF11205CD; Wed, 10 Apr 2019 12:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 XUBKEUaezhJS; Wed, 10 Apr 2019 12:40:51 -0700 (PDT)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840103.outbound.protection.outlook.com [40.107.84.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4E1120458; Wed, 10 Apr 2019 12:40:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FxbuV/RBrIG06m4N5gkjDwGK+SaYiLEMKIG3Bx8LhzM=; b=DP8CXd1GmN0LDfDi2/Q2uTgPYQC7Gpl6LqPCRAn5fEE31C046+kdEmPvih43dX4c6wK4FlpYiLJ6TwoD+c6tQWWRkaQIfZAVXPCQgruCEItKFOaZ3CcAMbgjw7aVMsjBCtireo7D5Q+g5nJzPGtYT0b6o/PIpUPs2+bfl7CRH+g=
Received: from SN6PR09MB3167.namprd09.prod.outlook.com (20.177.250.204) by SN6PR09MB3167.namprd09.prod.outlook.com (20.177.250.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.21; Wed, 10 Apr 2019 19:40:48 +0000
Received: from SN6PR09MB3167.namprd09.prod.outlook.com ([fe80::694c:8a72:b9a7:5832]) by SN6PR09MB3167.namprd09.prod.outlook.com ([fe80::694c:8a72:b9a7:5832%2]) with mapi id 15.20.1771.021; Wed, 10 Apr 2019 19:40:48 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-sidrops-bgpsec-algs-rfc8208-bis@ietf.org" <draft-ietf-sidrops-bgpsec-algs-rfc8208-bis@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04: (with COMMENT)
Thread-Index: AQHU7nXgQI4Urnu4Ok+oIXvgvm0Y7qY1xJMA
Date: Wed, 10 Apr 2019 19:40:48 +0000
Message-ID: <SN6PR09MB3167A30C40919240CC87A6AE982E0@SN6PR09MB3167.namprd09.prod.outlook.com>
References: <155477430291.30201.17132123731441062502.idtracker@ietfa.amsl.com>
In-Reply-To: <155477430291.30201.17132123731441062502.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov;
x-originating-ip: [129.6.140.119]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c2b4e057-739b-4940-9b1f-08d6bdec6ec2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:SN6PR09MB3167;
x-ms-traffictypediagnostic: SN6PR09MB3167:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <SN6PR09MB3167AC79DAD16F1CDFCAC985982E0@SN6PR09MB3167.namprd09.prod.outlook.com>
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(136003)(346002)(366004)(396003)(13464003)(199004)(189003)(110136005)(966005)(86362001)(4326008)(52536014)(478600001)(74316002)(106356001)(6436002)(105586002)(33656002)(45080400002)(25786009)(2906002)(66066001)(55016002)(229853002)(5660300002)(54906003)(2171002)(316002)(26005)(6246003)(476003)(6506007)(102836004)(14444005)(7696005)(68736007)(8676002)(11346002)(3846002)(446003)(256004)(486006)(53546011)(6306002)(186003)(97736004)(305945005)(71200400001)(71190400001)(8936002)(6116002)(76176011)(53936002)(7736002)(14454004)(99286004)(9686003)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB3167; H:SN6PR09MB3167.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: GaA/DE2WVs+++jOv/aW9h/qIYPfXKiqQh3KdVdNRY6lwvVVCie8Iy8mey86xGlaNqCkdEMUaORF2Z1qyX0OoyhqPJzbdeZX6GuGe1/UNI1iLgOqt+fn88lY4eca6k5Pr+Ne1Aia2Ij2nauJ9Ugzk/MpIk1N2iFY1SIfvWgv8cd2+DRNACgkKCRZQMHR14+ji1LBy1/D1X7qCMlI+CtWazLes4JeHZkMQgcYJo3y/TXnFsvFoCidV/N8E086aS464oSOXMy8HSYUIhYBJzD2aynZ8HFNfcDfQhVAEA1vSEe+ohsodTgoATu+QIh8QiJrVql4q3xOBi14UhBgjwsuIbwZFC719abb8zUn6vtfQkiJuJ652R0U0edHue0ldFxomZm8GlSNAopKdMrlETdu76NEdzyTB65zj3fNdJYFdwCs=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: c2b4e057-739b-4940-9b1f-08d6bdec6ec2
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 19:40:48.5761 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB3167
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tdMpFum3nYTrBMXaLMyB3ImGSbY>
Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2019 19:40:55 -0000

Hi Benjamin,
Regarding your comments below:

* Comment to 2.2.1
Are we trying to talk about both?

oliver: I believe so, the certificate request maps the algorithm with the OID whereas certificates and BGPsec update only reference the OID. 
            Maybe Sean has a better answer?

* Comment to Section 7:

IANA has registered a single algorithm suite
identifier for the digest algorithm SHA-256 [SHS] and for the
signature algorithm ECDSA on the P-256 curve [RFC6090] [DSS].

oliver: I added "Originally for RFC8208, " so it reads:

Originally for RFC8208,  IANA has registered a single algorithm suite
identifier for the digest algorithm SHA-256 [SHS] and for the
signature algorithm ECDSA on the P-256 curve [RFC6090] [DSS].


* Comment to Appendix A:

oliver: I added the following wording as 3rd sentence under A.2. Keys

Note: Even though the certificates below are expired, they are still useful
within the constraint of this example.

Thanks,
Oliver



-----Original Message-----
From: Benjamin Kaduk via Datatracker <noreply@ietf.org> 
Sent: Monday, April 08, 2019 9:45 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis@ietf.org; Chris Morrow <morrowc@ops-netman.net>; sidrops-chairs@ietf.org; morrowc@ops-netman.net; sidrops@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04: (with COMMENT)
Importance: High

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=02%7C01%7Coliver.borchert%40nist.gov%7C0b38a8038df546710b0808d6bc8d01c8%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636903711146734052&amp;sdata=9l9LzM53uxCn0vK%2FR5NT4vwqWJImDTHqVRz0fzgO3k4%3D&amp;reserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sidrops-bgpsec-algs-rfc8208-bis%2F&amp;data=02%7C01%7Coliver.borchert%40nist.gov%7C0b38a8038df546710b0808d6bc8d01c8%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636903711146734052&amp;sdata=idOS%2BTmG1ubvRHm11vQ3alVBUitXf59KzK1%2B1UmBqr0%3D&amp;reserved=0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.2.1

   Hash algorithms are not identified by themselves in certificates or
   BGPsec UPDATE messages.  They are represented by an OID that combines
   the hash algorithm with the digital signature algorithm as follows:

   o  The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the Public-Key
      Cryptography Standards #10 (PKCS #10) signatureAlgorithm field
      [RFC2986] or in the Certificate Request Message Format (CRMF)
      POPOSigningKey algorithm field [RFC4211]; where the OID is placed
      depends on the certificate request format generated.

The first paragraph talks of "certificates" but this last sentence talks about "certificate request"s.  Are we trying to talk about both?

Section 7

The IANA considerations are perhaps not as accurate as they could be.
For example, we could say that the BGPsec Algorithm Suite Registry was originally created by RFC 8208 and has been updated to refer to this document, and similarly for the P256-SHA256 codepoint.
(Just moving the references over would seem to be even more appropriate if this document were fully Obsoleting 8208.)

Appendix A

Do we want to note that the certificates are expired but the examples are still useful within that constraint?  (They were valid at the time RFC 8208 was published but it seems imprudent to try to assume that the examples would always be valid, when writing a document such as this.)