[pkix] [Technical Errata Reported] RFC5280 (6414)
RFC Errata System <rfc-editor@rfc-editor.org> Thu, 28 January 2021 15:44 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839983A15BD for <pkix@ietfa.amsl.com>; Thu, 28 Jan 2021 07:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 rqZDxclPO94V for <pkix@ietfa.amsl.com>; Thu, 28 Jan 2021 07:44:27 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9833A15BB for <pkix@ietf.org>; Thu, 28 Jan 2021 07:44:27 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 4B40EF40715; Thu, 28 Jan 2021 07:44:20 -0800 (PST)
To: david.cooper@nist.gov, stefans@microsoft.com, stephen.farrell@cs.tcd.ie, sharon.boeyen@entrust.com, housley@vigilsec.com, wpolk@nist.gov, rdd@cert.org, kaduk@mit.edu, kent@bbn.com, stefan@aaa-sec.com
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rob@sectigo.com, pkix@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210128154420.4B40EF40715@rfc-editor.org>
Date: Thu, 28 Jan 2021 07:44:20 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/rLa6v4kOlD8BQaJBwnmwX4oxsrE>
Subject: [pkix] [Technical Errata Reported] RFC5280 (6414)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2021 15:44:29 -0000
The following errata report has been submitted for RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6414 -------------------------------------- Type: Technical Reported by: Rob Stradling <rob@sectigo.com> Section: 4.2.1.12 Original Text ------------- id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } -- TLS WWW server authentication -- Key usage bits that may be consistent: digitalSignature, -- keyEncipherment or keyAgreement Corrected Text -------------- id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } -- TLS WWW server authentication -- Key usage bits that may be consistent: digitalSignature -- and/or (keyEncipherment or keyAgreement) Notes ----- In https://github.com/zmap/zlint/issues/553 there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text. "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text. However, digitalSignature+keyEncipherment makes sense for an RSA leaf certificate, and digitalSignature+keyAgreement makes sense for an ECC leaf certificate. Both are widely used, to enable ephemeral and non-ephemeral TLS ciphersuites in conjunction with a single server certificate. Given that RFC5480 section 3 explicitly permits digitalSignature+keyAgreement in an ECC leaf certificate, I think it's likely that my proposed Corrected Text conveys the RFC5280 authors' intended meaning. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5280 (draft-ietf-pkix-rfc3280bis-11) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : May 2008 Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG
- [pkix] [Technical Errata Reported] RFC5280 (6414) RFC Errata System
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Russ Housley
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Benjamin Kaduk
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Rob Stradling
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Russ Housley
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Rob Stradling
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Stefan Santesson
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Rob Stradling
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Russ Housley
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Benjamin Kaduk
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Rob Stradling
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Paul Hoffman
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Benjamin Kaduk
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Paul Hoffman
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Stephen Farrell
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Dan Harkins
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Paul Hoffman
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Benjamin Kaduk
- Re: [pkix] [Technical Errata Reported] RFC5280 (6… Ryan Sleevi