Re: [certid] Comments on draft-saintandre-tls-server-id-check-04

[Peter Saint-Andre <[e-mail]>]

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/