From nobody Wed Apr 17 06:03:30 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29D120355 for ; Wed, 17 Apr 2019 06:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nP3bGTH6A_gb for ; Wed, 17 Apr 2019 06:03:26 -0700 (PDT) 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 41DFD12008D for ; Wed, 17 Apr 2019 06:03:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DF98CB82BAF; Wed, 17 Apr 2019 06:03:22 -0700 (PDT) To: simon@josefsson.org, ietf@augustcellars.com, rdd@cert.org, kaduk@mit.edu, daniel.migault@ericsson.com, rsalz@akamai.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: LIJUN.LIAO@HUAWEI.COM, curdle@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190417130322.DF98CB82BAF@rfc-editor.org> Date: Wed, 17 Apr 2019 06:03:22 -0700 (PDT) Archived-At: Subject: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 13:03:28 -0000 The following errata report has been submitted for RFC8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5696 -------------------------------------- Type: Technical Reported by: Lijun Liao Section: 5 Original Text ------------- If the keyUsage extension is present in a certification authority certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage extension MUST contain one or more of the following values: nonRepudiation; digitalSignature; keyCertSign; and cRLSign. Corrected Text -------------- If the keyUsage extension is present in a certification authority certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage extension MUST contain keyCertSign, and zero, one or more of the following values: nonRepudiation; digitalSignature; and cRLSign. Notes ----- The usage keyCertSign must be set in a CA certificate. 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. -------------------------------------- RFC8410 (draft-ietf-curdle-pkix-10) -------------------------------------- Title : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure Publication Date : August 2018 Author(s) : S. Josefsson, J. Schaad Category : PROPOSED STANDARD Source : CURves, Deprecating and a Little more Encryption Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 17 06:12:29 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8393712045C for ; Wed, 17 Apr 2019 06:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 bNu417SXX_52 for ; Wed, 17 Apr 2019 06:12:25 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA37C120334 for ; Wed, 17 Apr 2019 06:12:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9E9B6300AF2 for ; Wed, 17 Apr 2019 08:54:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5ufQ3w52Zslh for ; Wed, 17 Apr 2019 08:54:03 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 5A8B0300400; Wed, 17 Apr 2019 08:54:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Russ Housley In-Reply-To: <20190417130322.DF98CB82BAF@rfc-editor.org> Date: Wed, 17 Apr 2019 09:12:19 -0400 Cc: Simon Josefsson , Jim Schaad , "Roman D. Danyliw" , Ben Kaduk , daniel.migault@ericsson.com, Rich Salz , "LIJUN.LIAO@huawei.com" , curdle@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190417130322.DF98CB82BAF@rfc-editor.org> To: RFC Editor X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 13:12:28 -0000 I do not think this is correct. A CA could, for example, use one key = for signing certificates and a separate key for signing CRLs. Russ > On Apr 17, 2019, at 9:03 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8410, > "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in = the Internet X.509 Public Key Infrastructure". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5696 >=20 > -------------------------------------- > Type: Technical > Reported by: Lijun Liao >=20 > Section: 5 >=20 > Original Text > ------------- > If the keyUsage extension is present in a certification authority > certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage > extension MUST contain one or more of the following values: >=20 > nonRepudiation; > digitalSignature; > keyCertSign; and > cRLSign. >=20 > Corrected Text > -------------- > If the keyUsage extension is present in a certification authority > certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage > extension MUST contain keyCertSign, and zero, one or more of the > following values: >=20 > nonRepudiation; > digitalSignature; and > cRLSign. >=20 > Notes > ----- > The usage keyCertSign must be set in a CA certificate. >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8410 (draft-ietf-curdle-pkix-10) > -------------------------------------- > Title : Algorithm Identifiers for Ed25519, Ed448, = X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure > Publication Date : August 2018 > Author(s) : S. Josefsson, J. Schaad > Category : PROPOSED STANDARD > Source : CURves, Deprecating and a Little more Encryption > Area : Security > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Apr 17 06:26:55 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2207A120104 for ; Wed, 17 Apr 2019 06:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com 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 C_1UgZYUOkFs for ; Wed, 17 Apr 2019 06:26:51 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1C512008D for ; Wed, 17 Apr 2019 06:26:51 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id f36so12052898plb.5 for ; Wed, 17 Apr 2019 06:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=OzXUw8oB/wHabVtGi6oXyW4QF45qisMNg/3X+ys4F0I=; b=PB3XnQnjD6cBmGYz3v2LDb2JVGdRXQJiww08PmS0URLKMs9LuVOX9nu+HfpQ7Io1Vi Xkzq4qrtjrsKV7HBFV/XcoA0Y7yQU8b6BnX/8fjptZDmFSOrEMjX1SfCLjTHfV/nEBQ8 s/7N+P9KnETOtY2GVBYtawMgIOMt/5edAfvZo3PxGSFsZMx4DPKS7/x3sNEGQgOFrMN3 R2EuoeyytUepNI8BGtjl1Ewpl/NwlZxgpjp9eyP1IsFqFjmBqGgsaB2DHp+7q2gUzBMS VNWirEJrqj8HRROonUJEfyFHfa69mIeupot7hvIJOaWqS4Y+2ouLLEGkJiMYHXtUOcVP Uqbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=OzXUw8oB/wHabVtGi6oXyW4QF45qisMNg/3X+ys4F0I=; b=tBZbzp1eu4y+oa2o9XlQrp32G3mi09q9iojj1mnfLtCM2yXHEO67/0SDtPxkHgQtgK M+cWWwMzYsxUQIkCC2Hj9WijmhGqycbQI+4FdPEGOx5Q7Y9z9B9MxT0sYZQ/aW7ODFJ6 dIM6lWVdXHZ9X8m957vujovMNza80+eni+tblvx0XbxNrYKGrG/uSZhS7Nq7NcU1HLsL BcDW2rzqH6Yerosk565BUe06BB+WB/ZIjmbSrlOLsllHv9QfBy42ALHup4Alzw7+/PYY MJZZl6gyFPAiNHyzPJ0MDQWpFki3MQ2JRokWG4fF5WGQ/GajQvcRjI8xLTzi7zuzuY0W WE7w== X-Gm-Message-State: APjAAAVE29JKgNGn9h52iwnV2cdaOpVih9cs6/Y+zQm0YA8re0iyUWi2 PXr3UFTV0RnnPvi2+THO0KBKmsDQ X-Google-Smtp-Source: APXvYqx12fQmM/2Fna3zpIsWkgXvz6PFQjKDpnAbstRYksx741yrcuiwEXjU24SfOSChxSM+HGy3lg== X-Received: by 2002:a17:902:20c6:: with SMTP id v6mr3006126plg.276.1555507609992; Wed, 17 Apr 2019 06:26:49 -0700 (PDT) Received: from SantoshBrain ([2600:8800:6800:58f0:e47a:b119:647:c981]) by smtp.gmail.com with ESMTPSA id h4sm50050283pgv.61.2019.04.17.06.26.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 06:26:49 -0700 (PDT) From: "Santosh Chokhani" To: "'Russ Housley'" , "'RFC Editor'" Cc: "'Roman D. Danyliw'" , "'Simon Josefsson'" , , "'Rich Salz'" , "'Jim Schaad'" , , "'LIJUN.LIAO@huawei.com'" , "'Ben Kaduk'" References: <20190417130322.DF98CB82BAF@rfc-editor.org> In-Reply-To: Date: Wed, 17 Apr 2019 09:26:47 -0400 Message-ID: <022201d4f521$363efad0$a2bcf070$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLUA8nUwpstT/Ye8zWBxjlp5t/4tAH7IQXgpDJerhA= Content-Language: en-us Archived-At: Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 13:26:54 -0000 Russ, But if the CA is using a key to sign CRL, in the context of that key it is not a CA personality but a CRL issuer personality. -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Wednesday, April 17, 2019 9:12 AM To: RFC Editor Cc: Roman D. Danyliw ; Simon Josefsson ; daniel.migault@ericsson.com; Rich Salz ; Jim Schaad ; curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kaduk Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) I do not think this is correct. A CA could, for example, use one key for signing certificates and a separate key for signing CRLs. Russ > On Apr 17, 2019, at 9:03 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC8410, "Algorithm > Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5696 > > -------------------------------------- > Type: Technical > Reported by: Lijun Liao > > Section: 5 > > Original Text > ------------- > If the keyUsage extension is present in a certification authority > certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage > extension MUST contain one or more of the following values: > > nonRepudiation; > digitalSignature; > keyCertSign; and > cRLSign. > > Corrected Text > -------------- > If the keyUsage extension is present in a certification authority > certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage > extension MUST contain keyCertSign, and zero, one or more of the > following values: > > nonRepudiation; > digitalSignature; and > cRLSign. > > Notes > ----- > The usage keyCertSign must be set in a CA certificate. > > 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. > > -------------------------------------- > RFC8410 (draft-ietf-curdle-pkix-10) > -------------------------------------- > Title : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure > Publication Date : August 2018 > Author(s) : S. Josefsson, J. Schaad > Category : PROPOSED STANDARD > Source : CURves, Deprecating and a Little more Encryption > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Apr 17 06:38:10 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACD912008D for ; Wed, 17 Apr 2019 06:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 0HojZcONgt73 for ; Wed, 17 Apr 2019 06:38:07 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E114E120364 for ; Wed, 17 Apr 2019 06:38:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 70276300AEA for ; Wed, 17 Apr 2019 09:19:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LVomNAJoUkBE for ; Wed, 17 Apr 2019 09:19:43 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 9D7363004E7; Wed, 17 Apr 2019 09:19:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Russ Housley In-Reply-To: <022201d4f521$363efad0$a2bcf070$@gmail.com> Date: Wed, 17 Apr 2019 09:37:59 -0400 Cc: RFC Editor , "Roman D. Danyliw" , Simon Josefsson , daniel.migault@ericsson.com, Rich Salz , Jim Schaad , curdle@ietf.org, "LIJUN.LIAO@huawei.com" , Ben Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190417130322.DF98CB82BAF@rfc-editor.org> <022201d4f521$363efad0$a2bcf070$@gmail.com> To: Santosh Chokhani X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 13:38:09 -0000 Santosh: This is the exact way we have described the appropriate key usage bits = since RFC 3279. If this has confused any implementer over the last = decade and a half, I have not heard about it. Russ > On Apr 17, 2019, at 9:26 AM, Santosh Chokhani = wrote: >=20 > Russ, >=20 > But if the CA is using a key to sign CRL, in the context of that key = it is > not a CA personality but a CRL issuer personality. =20 >=20 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ = Housley > Sent: Wednesday, April 17, 2019 9:12 AM > To: RFC Editor > Cc: Roman D. Danyliw ; Simon Josefsson = ; > daniel.migault@ericsson.com; Rich Salz ; Jim Schaad > ; curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben = Kaduk > > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) >=20 > I do not think this is correct. A CA could, for example, use one key = for > signing certificates and a separate key for signing CRLs. >=20 > Russ >=20 >=20 >> On Apr 17, 2019, at 9:03 AM, RFC Errata System = > wrote: >>=20 >> The following errata report has been submitted for RFC8410, = "Algorithm=20 >> Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the = Internet > X.509 Public Key Infrastructure". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5696 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Lijun Liao >>=20 >> Section: 5 >>=20 >> Original Text >> ------------- >> If the keyUsage extension is present in a certification authority >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage >> extension MUST contain one or more of the following values: >>=20 >> nonRepudiation; >> digitalSignature; >> keyCertSign; and >> cRLSign. >>=20 >> Corrected Text >> -------------- >> If the keyUsage extension is present in a certification authority >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage >> extension MUST contain keyCertSign, and zero, one or more of the >> following values: >>=20 >> nonRepudiation; >> digitalSignature; and >> cRLSign. >>=20 >> Notes >> ----- >> The usage keyCertSign must be set in a CA certificate. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please=20= >> use "Reply All" to discuss whether it should be verified or rejected.=20= >> When a decision is reached, the verifying party can log in to change=20= >> the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC8410 (draft-ietf-curdle-pkix-10) >> -------------------------------------- >> Title : Algorithm Identifiers for Ed25519, Ed448, = X25519, > and X448 for Use in the Internet X.509 Public Key Infrastructure >> Publication Date : August 2018 >> Author(s) : S. Josefsson, J. Schaad >> Category : PROPOSED STANDARD >> Source : CURves, Deprecating and a Little more = Encryption >> Area : Security >> Stream : IETF >> Verifying Party : IESG >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Apr 17 06:53:50 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13506120156 for ; Wed, 17 Apr 2019 06:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com 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 UO7_29TwoHx2 for ; Wed, 17 Apr 2019 06:53:45 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D49D120104 for ; Wed, 17 Apr 2019 06:53:45 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id b3so12158346pfd.1 for ; Wed, 17 Apr 2019 06:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=3ssBi8xadDhZfMeMJXTn6tIWw7Ynb2NTmBvoB0x45ZE=; b=DC5ur3/73nqJwYPPRnfXDwCv64XS6T2nKBww8q16axf2SV2QdumnKyxPtJBEAWo+q6 GwaY+JW9H+7/VcPZl1t0oaEB9G2vYsrdPAsns6Pok3aqAM4auPgjCZ9UNK1kus8sAcKF QuMcBV+FMfF+PaZ3qCRC+CBeUrdN5+9J9LgRhgHxHT5L6etDm7Y9KVnnueb9iFW2C2Re rlLxiBRIRhU9tsPjGIH1bibLXd4+hsArwA4w4pJnr3Xz7U1e8VTsIISQ4CYtbgXVpa9+ /1r5zkkxoa/UDVWPVAVlNMbow3hfpGIpeIoVCGzWp21mqJoS31Bk2Ooc1e/HAV0wm36C 5Z9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=3ssBi8xadDhZfMeMJXTn6tIWw7Ynb2NTmBvoB0x45ZE=; b=D4lu2r6jPCwXF7RBw7tsbLUYFDbhl27KEDxroEhoZyTNTdJA1f8iJD9X7Op6lDMm8p B7sj/oTcSzzq4PT87fEuK2igyF3/l1F6PwMcTg2jdH91c91ZN58Kqt8B92hKIMfuGeH9 RlR8052FL6sPxKtLvk5+ZNY61TMrnaUVjhElBOgC/jOVbWCe8ijG72w58NTV6Tf8mzvx DGyHh0HKuwq5IzJj1eSUI2dql9INjrOuuNSpPhbJgvPSSDaNA1b+SYcyYJMIaGbGXj70 UlUjXz+1hGrsUJpq7M4pr2yPUHlmllZf6UXykyGO7NNua8wfYvLZ6HmKNJtMwpi0lfd+ 07Sw== X-Gm-Message-State: APjAAAXUL8l+13Uuz4NuUxRaLirNsxBRsuLKNkphuPLwGLBfbPoz5eaj bULuUvCvC1TcRLuF69fPqDmQvESh X-Google-Smtp-Source: APXvYqyBnb4urjju6bn1IvPO5KKl9RnFxT0H1XWTzKiXNawFMBEKHTTwy1vDb4/8K3YvlcnWXdrHdg== X-Received: by 2002:a63:c112:: with SMTP id w18mr84045096pgf.200.1555509224762; Wed, 17 Apr 2019 06:53:44 -0700 (PDT) Received: from SantoshBrain ([2600:8800:6800:58f0:e47a:b119:647:c981]) by smtp.gmail.com with ESMTPSA id g5sm42046089pfo.53.2019.04.17.06.53.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 06:53:43 -0700 (PDT) From: "Santosh Chokhani" To: "'Russ Housley'" Cc: "'RFC Editor'" , "'Roman D. Danyliw'" , "'Simon Josefsson'" , , "'Rich Salz'" , "'Jim Schaad'" , , "'LIJUN.LIAO@huawei.com'" , "'Ben Kaduk'" References: <20190417130322.DF98CB82BAF@rfc-editor.org> <022201d4f521$363efad0$a2bcf070$@gmail.com> In-Reply-To: Date: Wed, 17 Apr 2019 09:53:42 -0400 Message-ID: <027801d4f524$f8b11690$ea1343b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLUA8nUwpstT/Ye8zWBxjlp5t/4tAH7IQXgAXYF7NMAncbPAaQhyN3Q Content-Language: en-us Archived-At: Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 13:53:48 -0000 Agree Russ in the sense that I have never seen a CA not issue CRL also. It might delegate CRL issuance to other authorities as well, but I have not seen an implementation where a CA does not generate a CRL and does not provide it to at least one RP, be it OCSP Responder. But if these folks are implementing a CA without CRL issuance, they might want this. On the other hand, I do not see CA having all these other bits as well. There is no security issue if the CA has CRL issuance bit even if it does not issue a CRL. So, I could go either way on this Errata since it does not move the security needle for me. -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, April 17, 2019 9:38 AM To: Santosh Chokhani Cc: RFC Editor ; Roman D. Danyliw ; Simon Josefsson ; daniel.migault@ericsson.com; Rich Salz ; Jim Schaad ; curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kaduk Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) Santosh: This is the exact way we have described the appropriate key usage bits since RFC 3279. If this has confused any implementer over the last decade and a half, I have not heard about it. Russ > On Apr 17, 2019, at 9:26 AM, Santosh Chokhani wrote: > > Russ, > > But if the CA is using a key to sign CRL, in the context of that key > it is not a CA personality but a CRL issuer personality. > > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ > Housley > Sent: Wednesday, April 17, 2019 9:12 AM > To: RFC Editor > Cc: Roman D. Danyliw ; Simon Josefsson > ; daniel.migault@ericsson.com; Rich Salz > ; Jim Schaad ; > curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kaduk > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > I do not think this is correct. A CA could, for example, use one key > for signing certificates and a separate key for signing CRLs. > > Russ > > >> On Apr 17, 2019, at 9:03 AM, RFC Errata System >> > wrote: >> >> The following errata report has been submitted for RFC8410, >> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use >> in the Internet > X.509 Public Key Infrastructure". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5696 >> >> -------------------------------------- >> Type: Technical >> Reported by: Lijun Liao >> >> Section: 5 >> >> Original Text >> ------------- >> If the keyUsage extension is present in a certification authority >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage >> extension MUST contain one or more of the following values: >> >> nonRepudiation; >> digitalSignature; >> keyCertSign; and >> cRLSign. >> >> Corrected Text >> -------------- >> If the keyUsage extension is present in a certification authority >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage >> extension MUST contain keyCertSign, and zero, one or more of the >> following values: >> >> nonRepudiation; >> digitalSignature; and >> cRLSign. >> >> Notes >> ----- >> The usage keyCertSign must be set in a CA certificate. >> >> 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. >> >> -------------------------------------- >> RFC8410 (draft-ietf-curdle-pkix-10) >> -------------------------------------- >> Title : Algorithm Identifiers for Ed25519, Ed448, X25519, > and X448 for Use in the Internet X.509 Public Key Infrastructure >> Publication Date : August 2018 >> Author(s) : S. Josefsson, J. Schaad >> Category : PROPOSED STANDARD >> Source : CURves, Deprecating and a Little more Encryption >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Apr 17 07:41:45 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B956C12014E for ; Wed, 17 Apr 2019 07:41:43 -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=ericsson.com 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 BccGkc53qNu3 for ; Wed, 17 Apr 2019 07:41:40 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740073.outbound.protection.outlook.com [40.107.74.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E083D120021 for ; Wed, 17 Apr 2019 07:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PRAaCZyALRLSeYLoZ04f666Edl0hRnb8bjAqXLozNIM=; b=e0yjhYzaRQDDfuromEglvv/kKG7RVL/LZePCAo+r6hsm57mEnNXkjTEEp/jj1od3E6Oi/FCX4Ii9yyCdvvBUe/6terZ5q3B5gpFtxRKSCZSQjLLp7CR0nBxDudxVeoCTmXujH05kVJ8LQNDMNvmm98YukzFHIhvrRzs8pnVh5ds= Received: from MN2PR15MB3310.namprd15.prod.outlook.com (20.179.21.142) by MN2PR15MB3168.namprd15.prod.outlook.com (20.179.23.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Wed, 17 Apr 2019 14:41:35 +0000 Received: from MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::3568:7582:3c7d:6f18]) by MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::3568:7582:3c7d:6f18%2]) with mapi id 15.20.1792.018; Wed, 17 Apr 2019 14:41:35 +0000 From: Daniel Migault To: Santosh Chokhani , 'Russ Housley' CC: 'RFC Editor' , "'Roman D. Danyliw'" , 'Simon Josefsson' , 'Rich Salz' , 'Jim Schaad' , "curdle@ietf.org" , "'LIJUN.LIAO@huawei.com'" , 'Ben Kaduk' Thread-Topic: [Curdle] [Technical Errata Reported] RFC8410 (5696) Thread-Index: AQHU9R4KByQWCPqVukWiHdpPGlSoV6ZAVCKAgAAEC4CAAAMhgIAABGQAgAAKPcA= Date: Wed, 17 Apr 2019 14:41:35 +0000 Message-ID: References: <20190417130322.DF98CB82BAF@rfc-editor.org> <022201d4f521$363efad0$a2bcf070$@gmail.com> <027801d4f524$f8b11690$ea1343b0$@gmail.com> In-Reply-To: <027801d4f524$f8b11690$ea1343b0$@gmail.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=daniel.migault@ericsson.com; x-originating-ip: [70.80.131.240] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: acdb5203-3dfd-4079-02c9-08d6c342ca80 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR15MB3168; x-ms-traffictypediagnostic: MN2PR15MB3168: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(366004)(346002)(136003)(199004)(189003)(13464003)(102836004)(81156014)(8936002)(81166006)(26005)(68736007)(66574012)(11346002)(8676002)(486006)(186003)(76176011)(14454004)(476003)(53546011)(446003)(86362001)(74316002)(5660300002)(97736004)(52536014)(71190400001)(2906002)(71200400001)(7736002)(6116002)(3846002)(305945005)(6506007)(25786009)(93886005)(316002)(6436002)(110136005)(4326008)(33656002)(44832011)(256004)(229853002)(54906003)(7696005)(99286004)(6306002)(966005)(6246003)(14444005)(9686003)(7416002)(55016002)(106356001)(66066001)(53936002)(105586002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR15MB3168; H:MN2PR15MB3310.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: y4H+C8lqRNhd+e3uggsu+xCLIrQ2zMtWjpue+REgp3yIoyLOOuwiJ9/KapFjvR1DkZ5sqF2V2TIjFXGsTw1hNZRqPUpKDeHHDbTIjVmOYzWN16dz5hD8tjQAYCpvg1zAJJ2AiszvFKiTylo00iBeCe/wZzy7r51W7sMBMG05fiafySbNysvvz8Ruo8VvRflRT5/lmGIbd7HVWMmSD1TChcMTFvbYrXXiI84DmV8cqhEc1NbXE8g/0POtbLKRHJ6j84t0eABu37sLdPY5dw03DdOLpT1/IPkToKRoOCQDRvkWIqP5MpOWIK/epmYCxn+px+9Q0LDVmVvW9TpUus7NH3gb/Ppughvtcs6R0XKyg4cFwHeZETl+4DDQpjbKuqKfZEVVmctoHl0uQV0g56WEbHWV8BuGa1OR1pXFSS8BVbQ= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: acdb5203-3dfd-4079-02c9-08d6c342ca80 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 14:41:35.1178 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB3168 Archived-At: Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 14:41:44 -0000 Hi,=20 Thank you Lijun Liao for the comment and taking the time to improve our doc= uments.=20 I believe the confusion is that certificate authority are not restricted to= emit certificate with KeyCertSign usage and cA constraint. For example, th= ey could emit a certificate that is used *only* to validate CRLs. This cert= ificate will have the keyUsage set to cRLSign. nonRepudiation, digitalSigna= ture, cRLSign would not be selected as it indicates the key could be used f= or other purposes. Other combinations using may consider one or a combinati= on of keyUsage KeyCertSign. nonRepudiation, digitalSignature, cRLSign. If my understanding is correct, mandating KeyCertSign is not correct and th= e current text catches all possibilities. The text could have explicitly me= ntioned that certificate may emit certificate that are only restricted to t= he validation of certificate signature. However, I am not sure that would c= larify the purpose of the document nor justify an errata. Thus, I am wonder= ing if we can agree the issue has been solved and close the request for err= ata. Yours,=20 Daniel=20 =20 -----Original Message----- From: Santosh Chokhani =20 Sent: Wednesday, April 17, 2019 9:54 AM To: 'Russ Housley' Cc: 'RFC Editor' ; 'Roman D. Danyliw' ; 'Simon Josefsson' ; Daniel Migault ; 'Rich Salz' ; 'Jim Schaad' ; curdle@ietf.org; 'LIJUN.LIAO@huawei.com' ; 'Ben Kaduk' Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) Agree Russ in the sense that I have never seen a CA not issue CRL also. It= might delegate CRL issuance to other authorities as well, but I have not s= een an implementation where a CA does not generate a CRL and does not provi= de it to at least one RP, be it OCSP Responder. But if these folks are implementing a CA without CRL issuance, they might w= ant this. =20 On the other hand, I do not see CA having all these other bits as well. There is no security issue if the CA has CRL issuance bit even if it does n= ot issue a CRL. So, I could go either way on this Errata since it does not move the securit= y needle for me. -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, April 17, 2019 9:38 AM To: Santosh Chokhani Cc: RFC Editor ; Roman D. Danyliw = ; Simon Josefsson ; daniel.migault@ericsson.com; Rich = Salz ; Jim Schaad ; curdle@ietf.o= rg; LIJUN.LIAO@huawei.com; Ben Kaduk Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) Santosh: This is the exact way we have described the appropriate key usage bits sinc= e RFC 3279. If this has confused any implementer over the last decade and = a half, I have not heard about it. Russ > On Apr 17, 2019, at 9:26 AM, Santosh Chokhani=20 > wrote: >=20 > Russ, >=20 > But if the CA is using a key to sign CRL, in the context of that key=20 > it is not a CA personality but a CRL issuer personality. >=20 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ=20 > Housley > Sent: Wednesday, April 17, 2019 9:12 AM > To: RFC Editor > Cc: Roman D. Danyliw ; Simon Josefsson=20 > ; daniel.migault@ericsson.com; Rich Salz=20 > ; Jim Schaad ;=20 > curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kaduk > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) >=20 > I do not think this is correct. A CA could, for example, use one key=20 > for signing certificates and a separate key for signing CRLs. >=20 > Russ >=20 >=20 >> On Apr 17, 2019, at 9:03 AM, RFC Errata System=20 >> > wrote: >>=20 >> The following errata report has been submitted for RFC8410,=20 >> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use=20 >> in the Internet > X.509 Public Key Infrastructure". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5696 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Lijun Liao >>=20 >> Section: 5 >>=20 >> Original Text >> ------------- >> If the keyUsage extension is present in a certification authority=20 >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage=20 >> extension MUST contain one or more of the following values: >>=20 >> nonRepudiation; >> digitalSignature; >> keyCertSign; and >> cRLSign. >>=20 >> Corrected Text >> -------------- >> If the keyUsage extension is present in a certification authority=20 >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage=20 >> extension MUST contain keyCertSign, and zero, one or more of the=20 >> following values: >>=20 >> nonRepudiation; >> digitalSignature; and >> cRLSign. >>=20 >> Notes >> ----- >> The usage keyCertSign must be set in a CA certificate. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please=20 >> 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=20 >> the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC8410 (draft-ietf-curdle-pkix-10) >> -------------------------------------- >> Title : Algorithm Identifiers for Ed25519, Ed448, X25519, > and X448 for Use in the Internet X.509 Public Key Infrastructure >> Publication Date : August 2018 >> Author(s) : S. Josefsson, J. Schaad >> Category : PROPOSED STANDARD >> Source : CURves, Deprecating and a Little more Encryption >> Area : Security >> Stream : IETF >> Verifying Party : IESG >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From lijun.liao@huawei.com Wed Apr 17 06:41:42 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC86120364 for ; Wed, 17 Apr 2019 06:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 deug6EyNfGX0 for ; Wed, 17 Apr 2019 06:41:40 -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 39A2512034A for ; Wed, 17 Apr 2019 06:41:40 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 175959D9722345854B3B; Wed, 17 Apr 2019 14:41:38 +0100 (IST) Received: from LHREML505-MBX.china.huawei.com ([169.254.10.69]) by LHREML710-CAH.china.huawei.com ([10.201.108.33]) with mapi id 14.03.0415.000; Wed, 17 Apr 2019 14:41:35 +0100 From: Lijun Liao To: Russ Housley , Santosh Chokhani CC: RFC Editor , "Roman D. Danyliw" , Simon Josefsson , "daniel.migault@ericsson.com" , Rich Salz , Jim Schaad , "curdle@ietf.org" , Ben Kaduk Thread-Topic: [Curdle] [Technical Errata Reported] RFC8410 (5696) Thread-Index: AQHU9R4EeHgZB3LN3kmX7XL5F2yT2KZAQ1+AgAAEC4CAAAMhgIAAEPRV Date: Wed, 17 Apr 2019 13:41:34 +0000 Message-ID: References: <20190417130322.DF98CB82BAF@rfc-editor.org> <022201d4f521$363efad0$a2bcf070$@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.161.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Wed, 17 Apr 2019 07:46:32 -0700 Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 13:43:50 -0000 I am with Santosh.=0A= =0A= As the definition of RFC 5280 Section 5:=0A= =0A= " CRL issuers issue CRLs. The CRL issuer is either the CA or an entity= =0A= that has been authorized by the CA to issue CRLs. CAs publish CRLs=0A= to provide status information about the certificates they issued.=0A= However, a CA may delegate this responsibility to another trusted=0A= authority.=0A= "=0A= =0A= If a CA only issues CRL, then =0A= "CAs publish CRLs=0A= to provide status information about the --certificates they issued---."= =0A= conflicts itself.=0A= =0A= Lijun=0A= ________________________________________=0A= From: Russ Housley [housley@vigilsec.com]=0A= Sent: Wednesday, April 17, 2019 1:37 PM=0A= To: Santosh Chokhani=0A= Cc: RFC Editor; Roman D. Danyliw; Simon Josefsson; daniel.migault@ericsson.= com; Rich Salz; Jim Schaad; curdle@ietf.org; Lijun Liao; Ben Kaduk=0A= Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696)=0A= =0A= Santosh:=0A= =0A= This is the exact way we have described the appropriate key usage bits sinc= e RFC 3279. If this has confused any implementer over the last decade and = a half, I have not heard about it.=0A= =0A= Russ=0A= =0A= =0A= > On Apr 17, 2019, at 9:26 AM, Santosh Chokhani wrote:=0A= >=0A= > Russ,=0A= >=0A= > But if the CA is using a key to sign CRL, in the context of that key it i= s=0A= > not a CA personality but a CRL issuer personality.=0A= >=0A= > -----Original Message-----=0A= > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley= =0A= > Sent: Wednesday, April 17, 2019 9:12 AM=0A= > To: RFC Editor =0A= > Cc: Roman D. Danyliw ; Simon Josefsson ;=0A= > daniel.migault@ericsson.com; Rich Salz ; Jim Schaad=0A= > ; curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kad= uk=0A= > =0A= > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696)=0A= >=0A= > I do not think this is correct. A CA could, for example, use one key for= =0A= > signing certificates and a separate key for signing CRLs.=0A= >=0A= > Russ=0A= >=0A= >=0A= >> On Apr 17, 2019, at 9:03 AM, RFC Errata System =0A= > wrote:=0A= >>=0A= >> The following errata report has been submitted for RFC8410, "Algorithm= =0A= >> Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet= =0A= > X.509 Public Key Infrastructure".=0A= >>=0A= >> --------------------------------------=0A= >> You may review the report below and at:=0A= >> http://www.rfc-editor.org/errata/eid5696=0A= >>=0A= >> --------------------------------------=0A= >> Type: Technical=0A= >> Reported by: Lijun Liao =0A= >>=0A= >> Section: 5=0A= >>=0A= >> Original Text=0A= >> -------------=0A= >> If the keyUsage extension is present in a certification authority=0A= >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage=0A= >> extension MUST contain one or more of the following values:=0A= >>=0A= >> nonRepudiation;=0A= >> digitalSignature;=0A= >> keyCertSign; and=0A= >> cRLSign.=0A= >>=0A= >> Corrected Text=0A= >> --------------=0A= >> If the keyUsage extension is present in a certification authority=0A= >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage=0A= >> extension MUST contain keyCertSign, and zero, one or more of the=0A= >> following values:=0A= >>=0A= >> nonRepudiation;=0A= >> digitalSignature; and=0A= >> cRLSign.=0A= >>=0A= >> Notes=0A= >> -----=0A= >> The usage keyCertSign must be set in a CA certificate.=0A= >>=0A= >> Instructions:=0A= >> -------------=0A= >> This erratum is currently posted as "Reported". If necessary, please=0A= >> use "Reply All" to discuss whether it should be verified or rejected.=0A= >> When a decision is reached, the verifying party can log in to change=0A= >> the status and edit the report, if necessary.=0A= >>=0A= >> --------------------------------------=0A= >> RFC8410 (draft-ietf-curdle-pkix-10)=0A= >> --------------------------------------=0A= >> Title : Algorithm Identifiers for Ed25519, Ed448, X25519,= =0A= > and X448 for Use in the Internet X.509 Public Key Infrastructure=0A= >> Publication Date : August 2018=0A= >> Author(s) : S. Josefsson, J. Schaad=0A= >> Category : PROPOSED STANDARD=0A= >> Source : CURves, Deprecating and a Little more Encryption= =0A= >> Area : Security=0A= >> Stream : IETF=0A= >> Verifying Party : IESG=0A= >>=0A= >> _______________________________________________=0A= >> Curdle mailing list=0A= >> Curdle@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/curdle=0A= >=0A= > _______________________________________________=0A= > Curdle mailing list=0A= > Curdle@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/curdle=0A= >=0A= > _______________________________________________=0A= > Curdle mailing list=0A= > Curdle@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/curdle=0A= =0A= From nobody Wed Apr 17 07:53:21 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A0012032B for ; Wed, 17 Apr 2019 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 c2caSXvNPx93 for ; Wed, 17 Apr 2019 07:53:18 -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 CCA2312016B for ; Wed, 17 Apr 2019 07:53:17 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 097625F4D8F01EEC6379; Wed, 17 Apr 2019 15:53:16 +0100 (IST) Received: from LHREML505-MBX.china.huawei.com ([169.254.10.69]) by lhreml706-cah.china.huawei.com ([10.201.108.47]) with mapi id 14.03.0415.000; Wed, 17 Apr 2019 15:53:12 +0100 From: Lijun Liao To: Daniel Migault , Santosh Chokhani , 'Russ Housley' CC: 'RFC Editor' , "'Roman D. Danyliw'" , 'Simon Josefsson' , 'Rich Salz' , 'Jim Schaad' , "curdle@ietf.org" , 'Ben Kaduk' Thread-Topic: [Curdle] [Technical Errata Reported] RFC8410 (5696) Thread-Index: AQHU9R4EeHgZB3LN3kmX7XL5F2yT2KZAQ1+AgAAEC4CAAAMhgIAABGQAgAANYYCAABOB0A== Date: Wed, 17 Apr 2019 14:53:11 +0000 Message-ID: References: <20190417130322.DF98CB82BAF@rfc-editor.org> <022201d4f521$363efad0$a2bcf070$@gmail.com> <027801d4f524$f8b11690$ea1343b0$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.162.239] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 14:53:20 -0000 Hi Daniel, Thank you for your reply. I think the definition of "CA" is clearly to be an entity which issues cert= ificates. See below: ------ I am with Santosh. As the definition of RFC 5280 Section 5: " CRL issuers issue CRLs. The CRL issuer is either the CA or an entity that has been authorized by the CA to issue CRLs. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority. " If a CA only issues CRL, then "CAs publish CRLs to provide status information about the --certificates they issued---." conflicts itself. Lijun ________________________________________ -----Original Message----- From: Daniel Migault [mailto:daniel.migault@ericsson.com]=20 Sent: 2019=1B$BG/=1B(B4=1B$B7n=1B(B17=1B$BF|=1B(B 16:42 To: Santosh Chokhani ; 'Russ Housley' Cc: 'RFC Editor' ; 'Roman D. Danyliw' ; 'Simon Josefsson' ; 'Rich Salz' ; 'Jim Schaad' ; curdle@ietf.org; Lijun Liao ; 'Ben Kaduk' Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) Hi,=20 Thank you Lijun Liao for the comment and taking the time to improve our doc= uments.=20 I believe the confusion is that certificate authority are not restricted to= emit certificate with KeyCertSign usage and cA constraint. For example, th= ey could emit a certificate that is used *only* to validate CRLs. This cert= ificate will have the keyUsage set to cRLSign. nonRepudiation, digitalSigna= ture, cRLSign would not be selected as it indicates the key could be used f= or other purposes. Other combinations using may consider one or a combinati= on of keyUsage KeyCertSign. nonRepudiation, digitalSignature, cRLSign. If my understanding is correct, mandating KeyCertSign is not correct and th= e current text catches all possibilities. The text could have explicitly me= ntioned that certificate may emit certificate that are only restricted to t= he validation of certificate signature. However, I am not sure that would c= larify the purpose of the document nor justify an errata. Thus, I am wonder= ing if we can agree the issue has been solved and close the request for err= ata. Yours,=20 Daniel=20 =20 -----Original Message----- From: Santosh Chokhani =20 Sent: Wednesday, April 17, 2019 9:54 AM To: 'Russ Housley' Cc: 'RFC Editor' ; 'Roman D. Danyliw' ; 'Simon Josefsson' ; Daniel Migault ; 'Rich Salz' ; 'Jim Schaad' ; curdle@ietf.org; 'LIJUN.LIAO@huawei.com' ; 'Ben Kaduk' Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) Agree Russ in the sense that I have never seen a CA not issue CRL also. It= might delegate CRL issuance to other authorities as well, but I have not s= een an implementation where a CA does not generate a CRL and does not provi= de it to at least one RP, be it OCSP Responder. But if these folks are implementing a CA without CRL issuance, they might w= ant this. =20 On the other hand, I do not see CA having all these other bits as well. There is no security issue if the CA has CRL issuance bit even if it does n= ot issue a CRL. So, I could go either way on this Errata since it does not move the securit= y needle for me. -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, April 17, 2019 9:38 AM To: Santosh Chokhani Cc: RFC Editor ; Roman D. Danyliw = ; Simon Josefsson ; daniel.migault@ericsson.com; Rich = Salz ; Jim Schaad ; curdle@ietf.o= rg; LIJUN.LIAO@huawei.com; Ben Kaduk Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) Santosh: This is the exact way we have described the appropriate key usage bits sinc= e RFC 3279. If this has confused any implementer over the last decade and = a half, I have not heard about it. Russ > On Apr 17, 2019, at 9:26 AM, Santosh Chokhani=20 > wrote: >=20 > Russ, >=20 > But if the CA is using a key to sign CRL, in the context of that key=20 > it is not a CA personality but a CRL issuer personality. >=20 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ=20 > Housley > Sent: Wednesday, April 17, 2019 9:12 AM > To: RFC Editor > Cc: Roman D. Danyliw ; Simon Josefsson=20 > ; daniel.migault@ericsson.com; Rich Salz=20 > ; Jim Schaad ;=20 > curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kaduk > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) >=20 > I do not think this is correct. A CA could, for example, use one key=20 > for signing certificates and a separate key for signing CRLs. >=20 > Russ >=20 >=20 >> On Apr 17, 2019, at 9:03 AM, RFC Errata System=20 >> > wrote: >>=20 >> The following errata report has been submitted for RFC8410,=20 >> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use=20 >> in the Internet > X.509 Public Key Infrastructure". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5696 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Lijun Liao >>=20 >> Section: 5 >>=20 >> Original Text >> ------------- >> If the keyUsage extension is present in a certification authority=20 >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage=20 >> extension MUST contain one or more of the following values: >>=20 >> nonRepudiation; >> digitalSignature; >> keyCertSign; and >> cRLSign. >>=20 >> Corrected Text >> -------------- >> If the keyUsage extension is present in a certification authority=20 >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage=20 >> extension MUST contain keyCertSign, and zero, one or more of the=20 >> following values: >>=20 >> nonRepudiation; >> digitalSignature; and >> cRLSign. >>=20 >> Notes >> ----- >> The usage keyCertSign must be set in a CA certificate. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please=20 >> 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=20 >> the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC8410 (draft-ietf-curdle-pkix-10) >> -------------------------------------- >> Title : Algorithm Identifiers for Ed25519, Ed448, X25519, > and X448 for Use in the Internet X.509 Public Key Infrastructure >> Publication Date : August 2018 >> Author(s) : S. Josefsson, J. Schaad >> Category : PROPOSED STANDARD >> Source : CURves, Deprecating and a Little more Encryption >> Area : Security >> Stream : IETF >> Verifying Party : IESG >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Apr 17 15:48:34 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CB312021B for ; Wed, 17 Apr 2019 15:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 WVxBgKRWEn33 for ; Wed, 17 Apr 2019 15:48:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48A912015F for ; Wed, 17 Apr 2019 15:48:27 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Apr 2019 15:47:56 -0700 From: Jim Schaad To: 'Lijun Liao' , 'Daniel Migault' , 'Santosh Chokhani' , 'Russ Housley' CC: 'RFC Editor' , "'Roman D. Danyliw'" , 'Simon Josefsson' , 'Rich Salz' , , 'Ben Kaduk' References: <20190417130322.DF98CB82BAF@rfc-editor.org> <022201d4f521$363efad0$a2bcf070$@gmail.com> <027801d4f524$f8b11690$ea1343b0$@gmail.com> In-Reply-To: Date: Wed, 17 Apr 2019 15:47:54 -0700 Message-ID: <000001d4f56f$9af4b390$d0de1ab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLUA8nUwpstT/Ye8zWBxjlp5t/4tAH7IQXgAXYF7NMAncbPAQHfZZ4SAKrG8GYCk+d7V6P5bbNw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 22:48:33 -0000 When I look at this problem I see two cases where not setting the bit makes sense to me. 1. A CA certificate which is only intended to be a trust anchor may not have the bit set because the bit would not be checked in some implementations so it would not make any difference. 2. I need to know how you define what a CA is: If you say that a CA is identified based only on a Public Key then what is said below makes a degree of sense. However, if you say that a CA is identified based on its name rather than on its key you end up with some other cases where a CA could have a certificate issued to itself. A) It uses a separate certificate for issuing of CRLs so that this can be done online while the certificate signing needs to be done off-line. B) It uses a separate certificate for the purpose of running one of the various enrollment protocols. In both of these cases a certificate has been issued to the CA, but that certificate is not used for the purpose of creating certificates and thus setting a bit to that effect is incorrect. I come down in the school that the CA is an entity based on it's name and not on it's public key. Rolling over a public key does not change the fact that it is the same CA. For both of these reasons I do not believe that the errata is correct. Jim > -----Original Message----- > From: Lijun Liao > Sent: Wednesday, April 17, 2019 7:53 AM > To: Daniel Migault ; Santosh Chokhani > ; 'Russ Housley' > Cc: 'RFC Editor' ; 'Roman D. Danyliw' > ; 'Simon Josefsson' ; 'Rich Salz' > ; 'Jim Schaad' ; > curdle@ietf.org; 'Ben Kaduk' > Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > Hi Daniel, > > Thank you for your reply. > > I think the definition of "CA" is clearly to be an entity which issues > certificates. See below: > > ------ > I am with Santosh. > > As the definition of RFC 5280 Section 5: > > " CRL issuers issue CRLs. The CRL issuer is either the CA or an entity > that has been authorized by the CA to issue CRLs. CAs publish CRLs > to provide status information about the certificates they issued. > However, a CA may delegate this responsibility to another trusted > authority. > " > > If a CA only issues CRL, then > "CAs publish CRLs > to provide status information about the --certificates they issued---." > conflicts itself. > > Lijun > ________________________________________ > > -----Original Message----- > From: Daniel Migault [mailto:daniel.migault@ericsson.com] > Sent: 2019年4月17日 16:42 > To: Santosh Chokhani ; 'Russ Housley' > > Cc: 'RFC Editor' ; 'Roman D. Danyliw' > ; 'Simon Josefsson' ; 'Rich Salz' > ; 'Jim Schaad' ; > curdle@ietf.org; Lijun Liao ; 'Ben Kaduk' > > Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > Hi, > > Thank you Lijun Liao for the comment and taking the time to improve our > documents. > > I believe the confusion is that certificate authority are not restricted to emit > certificate with KeyCertSign usage and cA constraint. For example, they could > emit a certificate that is used *only* to validate CRLs. This certificate will have > the keyUsage set to cRLSign. nonRepudiation, digitalSignature, cRLSign would > not be selected as it indicates the key could be used for other purposes. > Other combinations using may consider one or a combination of keyUsage > KeyCertSign. nonRepudiation, digitalSignature, cRLSign. > > If my understanding is correct, mandating KeyCertSign is not correct and the > current text catches all possibilities. The text could have explicitly mentioned > that certificate may emit certificate that are only restricted to the validation > of certificate signature. However, I am not sure that would clarify the > purpose of the document nor justify an errata. Thus, I am wondering if we > can agree the issue has been solved and close the request for errata. > > Yours, > Daniel > > > > > > > -----Original Message----- > From: Santosh Chokhani > Sent: Wednesday, April 17, 2019 9:54 AM > To: 'Russ Housley' > Cc: 'RFC Editor' ; 'Roman D. Danyliw' > ; 'Simon Josefsson' ; Daniel Migault > ; 'Rich Salz' ; 'Jim Schaad' > ; curdle@ietf.org; 'LIJUN.LIAO@huawei.com' > ; 'Ben Kaduk' > Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > Agree Russ in the sense that I have never seen a CA not issue CRL also. It > might delegate CRL issuance to other authorities as well, but I have not seen > an implementation where a CA does not generate a CRL and does not > provide it to at least one RP, be it OCSP Responder. > > But if these folks are implementing a CA without CRL issuance, they might > want this. > > On the other hand, I do not see CA having all these other bits as well. > There is no security issue if the CA has CRL issuance bit even if it does not > issue a CRL. > > So, I could go either way on this Errata since it does not move the security > needle for me. > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Wednesday, April 17, 2019 9:38 AM > To: Santosh Chokhani > Cc: RFC Editor ; Roman D. Danyliw > ; Simon Josefsson ; > daniel.migault@ericsson.com; Rich Salz ; Jim Schaad > ; curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben > Kaduk > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > Santosh: > > This is the exact way we have described the appropriate key usage bits since > RFC 3279. If this has confused any implementer over the last decade and a > half, I have not heard about it. > > Russ > > > > On Apr 17, 2019, at 9:26 AM, Santosh Chokhani > > > wrote: > > > > Russ, > > > > But if the CA is using a key to sign CRL, in the context of that key > > it is not a CA personality but a CRL issuer personality. > > > > -----Original Message----- > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ > > Housley > > Sent: Wednesday, April 17, 2019 9:12 AM > > To: RFC Editor > > Cc: Roman D. Danyliw ; Simon Josefsson > > ; daniel.migault@ericsson.com; Rich Salz > > ; Jim Schaad ; > > curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kaduk > > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > > > I do not think this is correct. A CA could, for example, use one key > > for signing certificates and a separate key for signing CRLs. > > > > Russ > > > > > >> On Apr 17, 2019, at 9:03 AM, RFC Errata System > >> > > wrote: > >> > >> The following errata report has been submitted for RFC8410, > >> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use > >> in the Internet > > X.509 Public Key Infrastructure". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata/eid5696 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Lijun Liao > >> > >> Section: 5 > >> > >> Original Text > >> ------------- > >> If the keyUsage extension is present in a certification authority > >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage > >> extension MUST contain one or more of the following values: > >> > >> nonRepudiation; > >> digitalSignature; > >> keyCertSign; and > >> cRLSign. > >> > >> Corrected Text > >> -------------- > >> If the keyUsage extension is present in a certification authority > >> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage > >> extension MUST contain keyCertSign, and zero, one or more of the > >> following values: > >> > >> nonRepudiation; > >> digitalSignature; and > >> cRLSign. > >> > >> Notes > >> ----- > >> The usage keyCertSign must be set in a CA certificate. > >> > >> 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. > >> > >> -------------------------------------- > >> RFC8410 (draft-ietf-curdle-pkix-10) > >> -------------------------------------- > >> Title : Algorithm Identifiers for Ed25519, Ed448, X25519, > > and X448 for Use in the Internet X.509 Public Key Infrastructure > >> Publication Date : August 2018 > >> Author(s) : S. Josefsson, J. Schaad > >> Category : PROPOSED STANDARD > >> Source : CURves, Deprecating and a Little more Encryption > >> Area : Security > >> Stream : IETF > >> Verifying Party : IESG > >> > >> _______________________________________________ > >> Curdle mailing list > >> Curdle@ietf.org > >> https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > From nobody Wed Apr 24 10:42:41 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3D4120117 for ; Wed, 24 Apr 2019 10:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=digicert.com header.b=P/xMh3uv; dkim=pass (1024-bit key) header.d=digicert.com header.b=QXUofeVU 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 Its26mdNZf0c for ; Wed, 24 Apr 2019 10:42:35 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32BC1200F6 for ; Wed, 24 Apr 2019 10:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1556127753; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N/pTg7r6bAC3Fyg8xv9S7sRbmNojDx4mdNGVGbeNjtk=; b=P/xMh3uvjJ4MtzqUBUk07nm4eneA6/VmDuM9BKwCHSQgDbY5WopxWgo9kyZFbRGDQkfuc3nisZVHCC/vzZB1CpLJwoCFAKfV0dkzsuNZuHklklxEBnsz4mRHn4FnLD2wj9p0GCOkBUG/KXCwBqTocI8ZMrLBL1sTkbBnmhiIYSk= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp2051.outbound.protection.outlook.com [104.47.34.51]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-192-A6sHtxZQPhWWxPtLZHxLHw-1; Wed, 24 Apr 2019 13:42:31 -0400 X-MC-Unique: A6sHtxZQPhWWxPtLZHxLHw-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N/pTg7r6bAC3Fyg8xv9S7sRbmNojDx4mdNGVGbeNjtk=; b=QXUofeVU4bvFTkd/FQSLOW9TbFWzzGMV+NvVkN/KMYs0uHNkYuTbGm2JKhVkHHVJUxMl6GD5T3/LtOPszPYUPN0uLqYM7fL5Dz10MH8HiTyqsBdsP3i28I6iTSTTlb1EQ1dRaREhHenBNyWCifQyaV9gEtbpEsFcgcSQ3XyQSqg= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1507.namprd14.prod.outlook.com (10.172.149.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.17; Wed, 24 Apr 2019 17:42:28 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::e00b:5349:3d54:57e3]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::e00b:5349:3d54:57e3%8]) with mapi id 15.20.1813.017; Wed, 24 Apr 2019 17:42:28 +0000 From: Tim Hollebeek To: Jim Schaad , 'Lijun Liao' , 'Daniel Migault' , 'Santosh Chokhani' , 'Russ Housley' CC: "'Roman D. Danyliw'" , 'Simon Josefsson' , "curdle@ietf.org" , 'Rich Salz' , 'Ben Kaduk' , 'RFC Editor' Thread-Topic: [Curdle] [Technical Errata Reported] RFC8410 (5696) Thread-Index: AQHU9R37xTiQCDb6o0ChFIFP/cOR9qZAVCOAgAAECoCAAAMhgIAABGQAgAANYYCAAAM+gIAAhKIAgAqoJ7A= Date: Wed, 24 Apr 2019 17:42:28 +0000 Message-ID: References: <20190417130322.DF98CB82BAF@rfc-editor.org> <022201d4f521$363efad0$a2bcf070$@gmail.com> <027801d4f524$f8b11690$ea1343b0$@gmail.com> <000001d4f56f$9af4b390$d0de1ab0$@augustcellars.com> In-Reply-To: <000001d4f56f$9af4b390$d0de1ab0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [107.139.229.114] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 26b1e60f-c9d0-4e9b-3902-08d6c8dc385a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:BN6PR14MB1507; x-ms-traffictypediagnostic: BN6PR14MB1507: x-microsoft-antispam-prvs: x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39860400002)(346002)(376002)(396003)(13464003)(189003)(199004)(53936002)(33656002)(6306002)(256004)(55016002)(6436002)(99286004)(14444005)(93886005)(9686003)(5660300002)(44832011)(76176011)(7696005)(52536014)(486006)(229853002)(11346002)(446003)(476003)(99936001)(478600001)(66946007)(66574012)(6506007)(186003)(26005)(8936002)(14454004)(316002)(2906002)(8676002)(74316002)(81156014)(53546011)(7416002)(25786009)(97736004)(73956011)(7736002)(66066001)(305945005)(81166006)(66616009)(76116006)(66476007)(64756008)(66446008)(4326008)(71190400001)(6116002)(68736007)(30864003)(6246003)(86362001)(66556008)(102836004)(54906003)(3846002)(966005)(71200400001)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1507; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: My2eAPPMUsWC7aYlEFE0gf4m9x9I6U3tGT1hbrJTOsFyum1Vkdy7a3BWdUw2O48enSNyDNztA7nWyff19RbvRWiuesqV5ewKpnbliRFdbsgGYAEWhe0Z6lRuS4/MU/xZycH8VdOKVci3nzTu7Ryw4qPKXkrIoL/hswZIhM6MbAlMdUlOyp0EewhXLj2fGA30mAHXsP6UN2oTLH19pvdGLZrXGz+DnwZ7mYFakn9EtwgdyLcfhA9N0RghCC6jtAse9fvmEmGg/g3rYD/4RcyFwkUZxMIle/ZAbYdQfHzsYuQccniGbEsAP833WBLc3BJtGOIub4Axa4U34UPlM0Y3l3fMbfaW/CMC/gc1/9Q4M7jbmoRnog5dP3+jYIFoZqA2RGVVzbuLrXKsebDoPm3zIA81SQqTz/HuKhA4Dy5+Bg0= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_02ED_01D4FA8A.60F0C650" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26b1e60f-c9d0-4e9b-3902-08d6c8dc385a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 17:42:28.1509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1507 Archived-At: Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:42:40 -0000 ------=_NextPart_000_02ED_01D4FA8A.60F0C650 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit I agree with Jim's analysis. Regrettably, it is not explicitly clear what a "certification authority certificate" is, and as Jim notes, there is a reasonable reading where these certificates may not be trust anchors. This is the most reasonable reading to me, and matches existing practice. Even if the certificate is a trust anchor, one needs to be very careful about making explicit requirements about EKUs, as different implementations handle them in many different ways, and trust anchors often need to be able to interoperate with a wide variety of systems. My reading of this errata is that it is requesting a requirements change, and an errata is not the appropriate method to accomplish that. If someone desires such a requirement, it needs to be carefully considered and analyzed. But there isn't an error in the current document that requires correction. -Tim > -----Original Message----- > From: Curdle On Behalf Of Jim Schaad > Sent: Wednesday, April 17, 2019 3:48 PM > To: 'Lijun Liao' ; 'Daniel Migault' > ; 'Santosh Chokhani' > ; 'Russ Housley' > Cc: 'Roman D. Danyliw' ; 'Simon Josefsson' > ; curdle@ietf.org; 'Rich Salz' ; > 'Ben Kaduk' ; 'RFC Editor' > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > When I look at this problem I see two cases where not setting the bit makes > sense to me. > > 1. A CA certificate which is only intended to be a trust anchor may not have > the bit set because the bit would not be checked in some implementations so > it would not make any difference. > > 2. I need to know how you define what a CA is: If you say that a CA is > identified based only on a Public Key then what is said below makes a degree > of sense. However, if you say that a CA is identified based on its name rather > than on its key you end up with some other cases where a CA could have a > certificate issued to itself. A) It uses a separate certificate for issuing of CRLs > so that this can be done online while the certificate signing needs to be done > off-line. B) It uses a separate certificate for the purpose of running one of the > various enrollment protocols. In both of these cases a certificate has been > issued to the CA, but that certificate is not used for the purpose of creating > certificates and thus setting a bit to > that effect is incorrect. I come down in the school that the CA is an > entity based on it's name and not on it's public key. Rolling over a public key > does not change the fact that it is the same CA. > > For both of these reasons I do not believe that the errata is correct. > > Jim > > > > -----Original Message----- > > From: Lijun Liao > > Sent: Wednesday, April 17, 2019 7:53 AM > > To: Daniel Migault ; Santosh Chokhani > > ; 'Russ Housley' > > Cc: 'RFC Editor' ; 'Roman D. Danyliw' > > ; 'Simon Josefsson' ; 'Rich Salz' > > ; 'Jim Schaad' ; > > curdle@ietf.org; 'Ben Kaduk' > > Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > > > Hi Daniel, > > > > Thank you for your reply. > > > > I think the definition of "CA" is clearly to be an entity which issues > > certificates. See below: > > > > ------ > > I am with Santosh. > > > > As the definition of RFC 5280 Section 5: > > > > " CRL issuers issue CRLs. The CRL issuer is either the CA or an entity > > that has been authorized by the CA to issue CRLs. CAs publish CRLs > > to provide status information about the certificates they issued. > > However, a CA may delegate this responsibility to another trusted > > authority. > > " > > > > If a CA only issues CRL, then > > "CAs publish CRLs > > to provide status information about the --certificates they issued---." > > conflicts itself. > > > > Lijun > > ________________________________________ > > > > -----Original Message----- > > From: Daniel Migault [mailto:daniel.migault@ericsson.com] > > Sent: 2019年4月17日 16:42 > > To: Santosh Chokhani ; 'Russ Housley' > > > > Cc: 'RFC Editor' ; 'Roman D. Danyliw' > > ; 'Simon Josefsson' ; 'Rich Salz' > > ; 'Jim Schaad' ; > > curdle@ietf.org; Lijun Liao ; 'Ben Kaduk' > > > > Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > > > Hi, > > > > Thank you Lijun Liao for the comment and taking the time to improve > > our documents. > > > > I believe the confusion is that certificate authority are not > > restricted > to emit > > certificate with KeyCertSign usage and cA constraint. For example, > > they > could > > emit a certificate that is used *only* to validate CRLs. This > > certificate > will have > > the keyUsage set to cRLSign. nonRepudiation, digitalSignature, cRLSign > would > > not be selected as it indicates the key could be used for other purposes. > > Other combinations using may consider one or a combination of keyUsage > > KeyCertSign. nonRepudiation, digitalSignature, cRLSign. > > > > If my understanding is correct, mandating KeyCertSign is not correct > > and > the > > current text catches all possibilities. The text could have explicitly > mentioned > > that certificate may emit certificate that are only restricted to the > validation > > of certificate signature. However, I am not sure that would clarify > > the purpose of the document nor justify an errata. Thus, I am > > wondering if we can agree the issue has been solved and close the request > for errata. > > > > Yours, > > Daniel > > > > > > > > > > > > > > -----Original Message----- > > From: Santosh Chokhani > > Sent: Wednesday, April 17, 2019 9:54 AM > > To: 'Russ Housley' > > Cc: 'RFC Editor' ; 'Roman D. Danyliw' > > ; 'Simon Josefsson' ; Daniel > > Migault ; 'Rich Salz' ; > > 'Jim > Schaad' > > ; curdle@ietf.org; 'LIJUN.LIAO@huawei.com' > > ; 'Ben Kaduk' > > Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > > > Agree Russ in the sense that I have never seen a CA not issue CRL also. > It > > might delegate CRL issuance to other authorities as well, but I have > > not > seen > > an implementation where a CA does not generate a CRL and does not > > provide it to at least one RP, be it OCSP Responder. > > > > But if these folks are implementing a CA without CRL issuance, they > > might want this. > > > > On the other hand, I do not see CA having all these other bits as well. > > There is no security issue if the CA has CRL issuance bit even if it > > does > not > > issue a CRL. > > > > So, I could go either way on this Errata since it does not move the > security > > needle for me. > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Wednesday, April 17, 2019 9:38 AM > > To: Santosh Chokhani > > Cc: RFC Editor ; Roman D. Danyliw > > ; Simon Josefsson ; > > daniel.migault@ericsson.com; Rich Salz ; Jim Schaad > > ; curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben > > Kaduk > > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > > > Santosh: > > > > This is the exact way we have described the appropriate key usage bits > since > > RFC 3279. If this has confused any implementer over the last decade > > and a half, I have not heard about it. > > > > Russ > > > > > > > On Apr 17, 2019, at 9:26 AM, Santosh Chokhani > > > > > wrote: > > > > > > Russ, > > > > > > But if the CA is using a key to sign CRL, in the context of that key > > > it is not a CA personality but a CRL issuer personality. > > > > > > -----Original Message----- > > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ > > > Housley > > > Sent: Wednesday, April 17, 2019 9:12 AM > > > To: RFC Editor > > > Cc: Roman D. Danyliw ; Simon Josefsson > > > ; daniel.migault@ericsson.com; Rich Salz > > > ; Jim Schaad ; > > > curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kaduk > > > Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696) > > > > > > I do not think this is correct. A CA could, for example, use one > > > key for signing certificates and a separate key for signing CRLs. > > > > > > Russ > > > > > > > > >> On Apr 17, 2019, at 9:03 AM, RFC Errata System > > >> > > > wrote: > > >> > > >> The following errata report has been submitted for RFC8410, > > >> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use > > >> in the Internet > > > X.509 Public Key Infrastructure". > > >> > > >> -------------------------------------- > > >> You may review the report below and at: > > >> http://www.rfc-editor.org/errata/eid5696 > > >> > > >> -------------------------------------- > > >> Type: Technical > > >> Reported by: Lijun Liao > > >> > > >> Section: 5 > > >> > > >> Original Text > > >> ------------- > > >> If the keyUsage extension is present in a certification authority > > >> certificate that indicates id-Ed25519 or id-Ed448, then the > > >> keyUsage extension MUST contain one or more of the following values: > > >> > > >> nonRepudiation; > > >> digitalSignature; > > >> keyCertSign; and > > >> cRLSign. > > >> > > >> Corrected Text > > >> -------------- > > >> If the keyUsage extension is present in a certification authority > > >> certificate that indicates id-Ed25519 or id-Ed448, then the > > >> keyUsage extension MUST contain keyCertSign, and zero, one or more > > >> of the following values: > > >> > > >> nonRepudiation; > > >> digitalSignature; and > > >> cRLSign. > > >> > > >> Notes > > >> ----- > > >> The usage keyCertSign must be set in a CA certificate. > > >> > > >> 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. > > >> > > >> -------------------------------------- > > >> RFC8410 (draft-ietf-curdle-pkix-10) > > >> -------------------------------------- > > >> Title : Algorithm Identifiers for Ed25519, Ed448, X25519, > > > and X448 for Use in the Internet X.509 Public Key Infrastructure > > >> Publication Date : August 2018 > > >> Author(s) : S. Josefsson, J. Schaad > > >> Category : PROPOSED STANDARD > > >> Source : CURves, Deprecating and a Little more Encryption > > >> Area : Security > > >> Stream : IETF > > >> Verifying Party : IESG > > >> > > >> _______________________________________________ > > >> Curdle mailing list > > >> Curdle@ietf.org > > >> https://www.ietf.org/mailman/listinfo/curdle > > > > > > _______________________________________________ > > > Curdle mailing list > > > Curdle@ietf.org > > > https://www.ietf.org/mailman/listinfo/curdle > > > > > > _______________________________________________ > > > Curdle mailing list > > > Curdle@ietf.org > > > https://www.ietf.org/mailman/listinfo/curdle > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_02ED_01D4FA8A.60F0C650 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwNDI0MTc0MjEzWjAvBgkqhkiG9w0BCQQxIgQgdeYHuZo9liz9/S5Dux06vsRH9r93 eQVJCj5ETLSbv8UwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBABhWWSgLqi5On0S2KXF1FiqkpA44RC5UawrITgfSlabWJO5czpHDM8kIz50bIVaCiUgMWP// 3w9wcZ1GUmlvX1zxDB9jKWhr+5Tp8gZnY3sUFosMpYGYnZIU3mHem8jx9hBMNxx7SSIyxcUT17wt 8eg/lqvryQWQkg0dM26joNlUxXQNEW93Q5Ocank69MNiDpdbg8+k8QbhAq3pyOd9ddqdbM32vKZn +ZC4q1Lq0e4geIcd+vFdbwgoUkObBlnZA+QM/B4XNLJk/ackxC9m/rgQcSiYju15pw5DTxUhCPvQ OUI2AVFoFI0k+lPoX+JHM4ZYkFDCprXjm4yXG1oRoG0AAAAAAAA= ------=_NextPart_000_02ED_01D4FA8A.60F0C650-- From nobody Thu Apr 25 09:25:58 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C8E1202E6; Thu, 25 Apr 2019 09:25:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rsalz@akamai.com, curdle@ietf.org, curdle-chairs@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155620955192.32220.17485691979499266006.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2019 09:25:51 -0700 Archived-At: Subject: [Curdle] curdle - Not having a session at IETF 105 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 16:25:56 -0000 Rich Salz, a chair of the curdle working group, indicated that the curdle working group does not plan to hold a session at IETF 105. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Sun Apr 28 23:28:41 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E0712021F for ; Sun, 28 Apr 2019 23:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 iDcP4JvmkOnn for ; Sun, 28 Apr 2019 23:28:37 -0700 (PDT) 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 D01E2120072 for ; Sun, 28 Apr 2019 23:28:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F1B15B8223D; Sun, 28 Apr 2019 23:28:26 -0700 (PDT) To: simon@josefsson.org, ietf@augustcellars.com, rdd@cert.org, kaduk@mit.edu, daniel.migault@ericsson.com, rsalz@akamai.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: lijun.liao@gmail.com, curdle@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190429062826.F1B15B8223D@rfc-editor.org> Date: Sun, 28 Apr 2019 23:28:26 -0700 (PDT) Archived-At: Subject: [Curdle] [Editorial Errata Reported] RFC8410 (5707) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 06:28:39 -0000 The following errata report has been submitted for RFC8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5707 -------------------------------------- Type: Editorial Reported by: Lijun Liao Section: 10.2 Original Text ------------- - Corrected Text -------------- - Notes ----- In the example certificate, the critical-field of extensions keyUsage and subjectKeyIdentifier are of default value 'false'. They should not be included according to DER encoding rule. 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. -------------------------------------- RFC8410 (draft-ietf-curdle-pkix-10) -------------------------------------- Title : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure Publication Date : August 2018 Author(s) : S. Josefsson, J. Schaad Category : PROPOSED STANDARD Source : CURves, Deprecating and a Little more Encryption Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Apr 29 05:36:44 2019 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510B512033A for ; Mon, 29 Apr 2019 05:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Yp3QnUoSUtSu for ; Mon, 29 Apr 2019 05:36:40 -0700 (PDT) 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 885BF120344 for ; Mon, 29 Apr 2019 05:36:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DE193B81EB8; Mon, 29 Apr 2019 05:36:29 -0700 (PDT) To: simon@josefsson.org, ietf@augustcellars.com, rdd@cert.org, kaduk@mit.edu, daniel.migault@ericsson.com, rsalz@akamai.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: lijun.liao@gmail.com, curdle@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190429123629.DE193B81EB8@rfc-editor.org> Date: Mon, 29 Apr 2019 05:36:29 -0700 (PDT) Archived-At: Subject: [Curdle] [Editorial Errata Reported] RFC8410 (5709) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 12:36:42 -0000 The following errata report has been submitted for RFC8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5709 -------------------------------------- Type: Editorial Reported by: Lijun Liao Section: 10.2 Original Text ------------- - Corrected Text -------------- - Notes ----- The example certificate is a self-signed certificate containing X25519 public key. Unlike standard EC public key, the public key for key exchange is NOT the same as the one for digital signature in curve25519. That means, for the same private key, the public keys for X25519 and for Ed25519 are different. As a result, the public key in the self-signed certificate can NOT be used to verify the signature. In this context, please replace the example certificate by one containing the Ed25519 public key. 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. -------------------------------------- RFC8410 (draft-ietf-curdle-pkix-10) -------------------------------------- Title : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure Publication Date : August 2018 Author(s) : S. Josefsson, J. Schaad Category : PROPOSED STANDARD Source : CURves, Deprecating and a Little more Encryption Area : Security Stream : IETF Verifying Party : IESG