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

[Russ Housley <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 
> 发送时间: 2019年12月16日 17:59
> 收件人: chenyt-sjtu <[e-mail]>; 'Benjamin Kaduk' <[e-mail]>
> 抄送: 'Russ Housley' <[e-mail]>; 'IETF PKIX' <[e-mail]>; 'LAMPS WG' <[e-mail]>; 'David Cooper' <[e-mail]>; 'Stephen Farrell' <[e-mail]>; [e-mail]; 'Roman D. Danyliw' <[e-mail]>; 'RFC Editor' <[e-mail]>
> 主题: 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" <[e-mail]> 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 <[e-mail]> 
>    发送时间: 2019年12月16日 4:26
>    收件人: Benjamin Kaduk <[e-mail]>
>    抄送: Russ Housley <[e-mail]>; IETF PKIX <[e-mail]>; LAMPS WG <[e-mail]>; David Cooper <[e-mail]>; Stephen Farrell <[e-mail]>; [e-mail]; Roman D. Danyliw <[e-mail]>; [e-mail]; RFC Editor <[e-mail]>
>    主题: 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" <[e-mail]> 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" <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> 
>>>> 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
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
>