[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