Re: [pkix] [Technical Errata Reported] RFC5280 (5938)

Russ Housley <housley@vigilsec.com> Mon, 16 December 2019 20:08 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE6F12090B for <pkix@ietfa.amsl.com>; Mon, 16 Dec 2019 12:08:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 ipTstmOXyKsz for <pkix@ietfa.amsl.com>; Mon, 16 Dec 2019 12:08:28 -0800 (PST)
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 A401A12008C for <pkix@ietf.org>; Mon, 16 Dec 2019 12:08:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 085D2300B30 for <pkix@ietf.org>; Mon, 16 Dec 2019 15:08:27 -0500 (EST)
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 UVc8acEMoCj8 for <pkix@ietf.org>; Mon, 16 Dec 2019 15:08:21 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id CC8FA30046F; Mon, 16 Dec 2019 15:08:20 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <000001d5b40c$b29da220$17d8e660$@sjtu.edu.cn>
Date: Mon, 16 Dec 2019 15:08:21 -0500
Cc: Stefan Santesson <stefan@aaa-sec.com>, Ben Kaduk <kaduk@mit.edu>, IETF PKIX <pkix@ietf.org>, LAMPS WG <spasm@ietf.org>, David Cooper <david.cooper@nist.gov>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, wpolk@nist.gov, "Roman D. Danyliw" <rdd@cert.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <631490CF-AE40-4D16-8A1D-A799806A302E@vigilsec.com>
References: <000001d5b40c$b29da220$17d8e660$@sjtu.edu.cn>
To: chenyt-sjtu <chenyt@sjtu.edu.cn>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/uA0GhhKlaArFDxCmWdPtQxMGaj4>
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (5938)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2019 20:08:31 -0000

Yuting:

You need to perform path validation to a trust anchor, and then you can trust the binding of the subject public key to any or all of the names in the certificate.

Russ


> On Dec 16, 2019, at 7:31 AM, chenyt-sjtu <chenyt@sjtu.edu.cn> wrote:
> 
> Thank you, Stefan.
> 
> It seems that a path validation may not necessarily bind the subject 
> public key and the subject DN and/or the subjectAltName extension.
> I really suggest that the text can be tweaked for the right thing, :-)
> 
> Yuting
> 
> -----邮件原件-----
> 发件人: Stefan Santesson <stefan@aaa-sec.com> 
> 发送时间: 2019年12月16日 17:59
> 收件人: chenyt-sjtu <chenyt@sjtu.edu.cn>cn>; 'Benjamin Kaduk' <kaduk@mit.edu>
> 抄送: 'Russ Housley' <housley@vigilsec.com>om>; 'IETF PKIX' <pkix@ietf.org>rg>; 'LAMPS WG' <spasm@ietf.org>rg>; 'David Cooper' <david.cooper@nist.gov>ov>; 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>ie>; wpolk@nist.gov; 'Roman D. Danyliw' <rdd@cert.org>rg>; 'RFC Editor' <rfc-editor@rfc-editor.org>
> 主题: Re: [Technical Errata Reported] RFC5280 (5938)
> 
> Yuting,
> 
> There is nothing you must verify.
> If you trust the CA, you trust the CA to provide accurate information about the subject.
> You can safely ignore name information that is not relevant for you.
> 
> 
> Stefan Santesson 
> 
> On 2019-12-16, 01:42, "chenyt-sjtu" <chenyt@sjtu.edu.cn> wrote:
> 
>    I'm still curious of path validation.
> 
>    When we have a certificate with a subject DN and a subjectAltName, what should 
>    be "verified"? Is it the binding between the public key and (the subject DN and the 
>    subjectAltName)? Or it will be fine if we just need to bind the key to the subject DN. 
>    The validation results can be different when we have some bogus certificates.
> 
>    Regards,
>    Yuting
> 
>    -----邮件原件-----
>    发件人: Stefan Santesson <stefan@aaa-sec.com> 
>    发送时间: 2019年12月16日 4:26
>    收件人: Benjamin Kaduk <kaduk@mit.edu>
>    抄送: Russ Housley <housley@vigilsec.com>om>; IETF PKIX <pkix@ietf.org>rg>; LAMPS WG <spasm@ietf.org>rg>; David Cooper <david.cooper@nist.gov>ov>; Stephen Farrell <stephen.farrell@cs.tcd.ie>ie>; wpolk@nist.gov; Roman D. Danyliw <rdd@cert.org>rg>; chenyt@sjtu.edu.cn; RFC Editor <rfc-editor@rfc-editor.org>
>    主题: Re: [Technical Errata Reported] RFC5280 (5938)
> 
>    So I have no objection either. Technically you are right of course.
> 
>    My only point is that if you would pick any standards document of size apart to this level, you would probably come up with a large number of possible editorial erratas.
>    But again. There is nothing wrong with the suggested edit.
> 
> 
>    Stefan Santesson 
> 
>    On 2019-12-15, 19:49, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> 
>        While I agree that the original text is fine in isolation, I think the
>        document looks internally inconsistent when it says "Certification path
>        processing verifies the binding between the subject distinguished name
>        and/or subject alternative name and subject public key" in Section 6 and
>        then "The primary goal of path validation is to verify the binding between
>        a subject distinguished name or a subject alternative name and subject
>        public key, as represented in the target certificate, based on the public
>        key of the trust anchor" in Section 6.1.  A reader would rightly ask "what
>        is different?" between these two situations with one using "subject
>        distinguished name and/or subject alternative name" and the other using
>        "subject distinguished name or a subject alternative name".
> 
>        Resolving this sort of minor discrepancy even when the meaning is clear is
>        exactly what editorial errata are for.
> 
>        -Ben
> 
>        On Sun, Dec 15, 2019 at 05:38:12PM +0100, Stefan Santesson wrote:
>> I agree.
>> 
>> I don't think this type of nit picking belongs in an errata.
>> The concept of biding a key to information in a certificate is well understood.
>> 
>> Stefan Santesson 
>> 
>> On 2019-12-15, 17:23, "Russ Housley" <housley@vigilsec.com> wrote:
>> 
>>    I think the original text is fine.  It is not an exclusive or.
>> 
>>    Russ
>> 
>>> On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>>> 
>>> I think this looks pretty straightforward (though I'd tweak the "corrected
>>> text" to do the right thing with the automated tooling and possibly the
>>> "notes" as well before verifying).  Any thoughts for or against
>>> "verified"/"editorial"?
>>> 
>>> Thanks,
>>> 
>>> Ben
>>> 
>>> On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System wrote:
>>>> The following errata report has been submitted for RFC5280,
>>>> "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
>>>> 
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> https://www.rfc-editor.org/errata/eid5938
>>>> 
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Yuting Chen <chenyt@sjtu.edu.cn>
>>>> 
>>>> Section: 6.1
>>>> 
>>>> Original Text
>>>> -------------
>>>> The primary goal of path validation is to verify the binding between
>>>> a subject distinguished name or a subject alternative name and
>>>> subject public key, as represented in the target certificate, based
>>>> on the public key of the trust anchor. In most cases, the target
>>>> 
>>>> Corrected Text
>>>> --------------
>>>> The primary goal of path validation is to verify the binding between
>>>> | a subject distinguished name and/or a subject alternative name and
>>>> subject public key, as represented in the target certificate, based
>>>> on the public key of the trust anchor. In most cases, the target
>>>> 
>>>> Notes
>>>> -----
>>>> The correction conforms to the first paragraph, Sec. 6, "Certification 
>>>> path processing verifies the binding between the subject distinguished
>>>> name and/or subject alternative name and subject public key." 
>>>> 
>>>> In addition, it is not very clear in RFC 5280, given a certificate with
>>>> a non-empty subject DN and an SAN extension instance (critical or 
>>>> non-critical), which one (the subject DN, the SAN extension,  or they 
>>>> both) should be bound to the subject public key during path validation.
>>>> More explanations are needed.
>>>> 
>>>> Instructions:
>>>> -------------
>>>> This erratum is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party  
>>>> can log in to change the status and edit the report, if necessary. 
>>>> 
>>>> --------------------------------------
>>>> RFC5280 (draft-ietf-pkix-rfc3280bis-11)
>>>> --------------------------------------
>>>> Title               : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
>>>> Publication Date    : May 2008
>>>> Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Public-Key Infrastructure (X.509)
>>>> Area                : Security
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
>