Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938)

From: "chenyt-sjtu" <[email-masked]>
Date: Tue, 17 Dec 2019 09:47:21 +0800

Russ,

I agree. The goal of path validation is sufficiently clear; it is to verify the 
target key certificate, based on the public key of the trust anchor. 

I'd still suggest that "the binding between a subject distinguished name or 
a subject alternative name and subject public key" needs be changed to 
"the binding between a subject distinguished name and/or a subject alternative 
name and subject public key". It helps the readers understand the fact, i.e.,
everything in the certificate, if present, can be trusted after a path validation.

Regards,
Yuting

-----邮件原件-----
发件人: Russ Housley <[email-masked]> 
发送时间: 2019年12月17日 4:08
收件人: chenyt-sjtu <[email-masked]>
抄送: Stefan Santesson <[email-masked]>; Ben Kaduk <[email-masked]>; IETF PKIX <[email-masked]>; LAMPS WG <[email-masked]>; David Cooper <[email-masked]>; Stephen Farrell <[email-masked]>; [email-masked]; Roman D. Danyliw <[email-masked]>
主题: Re: [Technical Errata Reported] RFC5280 (5938)

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

---

From: "chenyt-sjtu" <[email-masked]>
Date: Wed, 18 Dec 2019 19:08:16 +0800

Hi, Stefan,

Got it!

I was actually stuck by some (but not many) inconsistent words and phrases (e.g., 
subject name, subject field, and then binding), although I could tweak them in my 
mind, :-) 

For example, in Section 4.1.2.6,

The subject name MAY be carried in the subject field and/or the subjectAltName extension. 
..If subject naming information is present only in the subjectAltName extension
(e.g., a key bound only to an email address or URI), then the subject
name MUST be an empty sequence and the subjectAltName extension MUST
be critical.

Here it should say, "...then the subject field MUST contain an empty sequence...".

Yuting

发件人: Stefan Santesson <[email-masked]> 
发送时间: 2019年12月18日 16:34
收件人: chenyt-sjtu <[email-masked]>; 'Salz, Rich' <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>
抄送: 'Roman D. Danyliw' <[email-masked]>; 'David Cooper' <[email-masked]>; [email-masked]; 'Russ Housley' <[email-masked]>; 'LAMPS WG' <[email-masked]>; 'Stephen Farrell' <[email-masked]>
主题: Re: [lamps] [Technical Errata Reported] RFC5280 (5938)

Yuting,

It seems that you are still stuck in backwards thinking, and I'm not sure I can unstack you in a single sentence.

We are trying to tell you that you don't verify the binding of a name as part of certificate validation.
You perform certificate validation so you can trust the information in the certificate.

Stefan Santesson 

On 2019-12-18, 02:50, "chenyt-sjtu" <[email-masked]> wrote:

    Hi, Rich,
    
    Thank you for explaining the word "binding". The validity and the subjectAltName
    can be trusted if the certificate can pass "path validation", right? 
    
    Binding is not a strict word. I found that public key certificates are defined as data 
    structures that "bind" public key values to subjects (Sec. 3.1). Should the "binding 
    between a subject and a subject key", rather than the "binding between a subject 
    distinguished name or a subject alternative name and subject public key" (Sec. 6.1), 
    get verified in a path validation?
    
    Yuting
    
    -----邮件原件-----
    发件人: Salz, Rich <[email-masked]> 
    发送时间: 2019年12月17日 22:40
    收件人: chenyt-sjtu <[email-masked]>; 'Stefan Santesson' <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>
    抄送: 'Roman D. Danyliw' <[email-masked]>; 'David Cooper' <[email-masked]>; [email-masked]; 'Russ Housley' <[email-masked]>; 'LAMPS WG' <[email-masked]>; 'IETF PKIX' <[email-masked]>; 'RFC Editor' <[email-masked]>; 'Stephen Farrell' <[email-masked]>
    主题: Re: [lamps] [Technical Errata Reported] RFC5280 (5938)
    
    The CA, when it signs a certificate, is saying that all of the information in the certificate is correct.
    
    By convention, we talk about "binding" the key to the SubjectDN, but all of the information -- notAfter, subjectAltName, etc -- are valid, if you trust the CA (or have a path to a chain up to a CA that you do trust). We don't talk about "binding" the key to its validity period.