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

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

Actually my concern is same as Ben's. There are three types of bindings 
(between the key and the subject) in RFC 5280. 

<Binding 1> "binding between the public key material and the subject
of the certificate" (Sec. 4.1.1.3), "binding between the subject 
and public key" (Sec. 8), "binding between a key and certificate 
subject" (Sec. 8),

<Binding 2> "binding between the subject distinguished name and/or 
subject alternative name and subject public key" (Sec. 6) and 
"binding between the name and subject public key" (Sec. 6.1),

<Binding 3> "binding between a subject distinguished name or a subject 
alternative name and subject public key" (Sec. 6.1).

If the three types of bindings are the same thing, it will be good if we can 
make them consistently presented. 

If they are different, some explanations can be made in Section 6. <Binding 1> 
should contain <Binding 2> or <Binding 3>. Then what are the other bindings in 
<Binding 1>? Are they remained unverified after a path validation?

Regards,

Yuting

-----邮件原件-----
发件人: chenyt-sjtu <[email-masked]> 
发送时间: 2019年12月18日 9:50
收件人: 'Salz, Rich' <[email-masked]>; 'Stefan Santesson' <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>
抄送: 'Roman D. Danyliw' <[email-masked]>; 'David Cooper' <[email-masked]>; [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)

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.

---

From: Peter Bowen <[email-masked]>
Date: Wed, 18 Dec 2019 13:39:49 -0800

> <Binding 1>? Are they remained unverified after a path validation?

In X.509 certificates, as defined in RFC 5280, contain fields.  A field is
roughly analogous to a ASN.1 component.

In 5280, each certificate has a single public key.  This public key is the
Subject Public Key and is stored in the Subject Public Key Info field in
the certificate (which can also be called the Subject Public Key field).

The Subject of a certificate is a person, service, system, or other
entity.  The Subject can have multiple identifiers (or names) that all
refer to the same Subject.  These identifiers can be encoded in the
certificate in Subject field (as a Distinguished Name), the Subject
Alternative Name extension, or both.

The certificate asserts a binding between the Subject and the Subject
Public Key.  As the various identifiers in the Subject and Subject
Alternative Name extension are all synonyms, they all refer to the same
entity and all are bound to the same public key.

While phrased slightly differently, as you point out, they all mean the
same thing.  Having inconsistent terminology makes translation very tricky,
as you have to understand whether there is meaningful difference that needs
to be retained.  I think the fully expressed version would be something
like:

"The primary goal of path validation is to verify the binding between the
subject identifier(s) and the subject public key info, as represented in
the target certificate, based on the public key of the trust anchor."  Note
that in current implementations of PKI, there are usually multiple trust
anchors, so you have to attempt path validation for each anchor and accept
the binding if any path validates.

Thanks,
Peter