On 5/29/10 11:46 AM, Peter Sylvester wrote: > some more details. > > In 1.1: > > > There is the possibility to indicate several identities: > > "Only a match between the client's reference identity and the server's > presented identity enables the client to be sure that the certificate > can legitimately be used to secure the connection." > ==> > "In general, a match between the client's reference identity and one of > the server's > presented identities is required to enable the client to be sure that > the certificate > can legitimately be used to authenticate the connection."
Ah, I see what you're getting at. Yes, the existing text is rather
informal, since later in the document we talk more precisely about
identifiers, not identity. I've reworded that paragraph as follows:
When a client connects to an
application server using Transport Layer Security [TLS] (or, less
commonly, [DTLS]), it references some conception of the server's
identity while attempting to establish a secure connection (e.g.,
"the web site at example.com"). Likewise, during TLS negotiation the
server presents its conception of the server's identity in the form
of a public-key certificate that was issued by a certification
authority in the context of the Internet Public Key Infrastructure
using X.509 [PKIX]. Informally, we can think of these identities as
the client's "reference identity" and the server's "presented
identity" (these rough ideas are defined more precisely later in this
document through the concept of particular identifiers). In general,
a client needs to verify that the server's presented identity matches
its reference identity so that it can be sure that the certificate
can legitimately be used to authenticate the connection.
> (see: "The application server is identified by a name or names carried in
> the subject field and/or the subjectAltName extension of the
> certificate.")
>
> "The Internet Public Key Infrastructure" sounds ambiguous quite right to
> me.
> - The only thing of a PKI in question that is ever transmitted
> and visible in the Internet might be the server's certificate.
> - There is no "Internet PKI" (like the DNS).
>
RFC 5280 has the title "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile". We're simply
inheriting from that, because it is a common baseline for this proposed
BCP and defines terms that are familiar to those who will use this
proposed BCP. If you have problems with RFC 5280, please take that up
with the authors of RFC 5280.
> "in the context of the Internet Public Key Infrastructure using X.509"
> ==>
> "in the context of a Public Key Infrastructure using X.509".
See above.
> Likewise, during TLS negotiation the server presents
> its conception of the server's identity
>
> Application protocols have traditionally specified their own rules
> for representing and verifying server identities.
>
> I suggest to replace "represent" by "present". (The word represent seems
> to be used interchangeable with present in the current text). I'd prefer
> even 'indicate' instead.
Your distinctions are quite subtle.
The server has a certificate. It presents (gives, hands over, shows,
offers) the certificate to the client during TLS negotiation. Thus
"present" seems appropriate in the first quoted sentence.
The server's certificate contains various information (e.g.,
subjectAltName extensions). That information is intended to represent
(depict, describe, symbolize, embody) the server's identity. Thus
"representing" seems appropriate in the second quoted sentence.
IMHO "indicate" is not a good substitute for "present" in the first
sentence or "represent" in the second sentence, because "indicate" is a
bit ambiguous -- it can mean either "point, show" (roughly equivalent to
"present") or "be a sign of" (roughly equivalent to "represent").
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
