$Id: draft-ietf-sip-domain-certs-00-rev.txt,v 1.1 2008/03/13 12:53:39 ekr Exp $
S 5.
The problem for proxyB is slightly more complex since it accepted the
TLS request passively. Thus, it does not possess an equivalent AUS
that proxyA did; instead, it uses local policies to consider the
client authenticated. The normative behavior for servers is provided
in Section 7.4.
I don't think this point is necessarily right. It's job is to primarily
to record the claimed identity from the SSL client. Why is this
problematic?
S 6.
Service providers MAY continue the practice of using existing
certificates for SIP usage with the identity conveyed in the Subject
field; however, such usage is NOT RECOMMENDED for new certificates,
which MUST contain the identity in the subjectAltName extension.
Will standard CAs give you certificates of with SAN set? If not,
this MUST seems to be too strong.
S 7.2.
What's the reason for forbidding wildcards?
S 7.4.
When a server accepts a TLS connection, it presents its own X.509
certificate to the client. To authenticate the client, the server
asks the client for a certificate. If the client possesses a
certificate, it is presented to the server. If the client does not
present a certificate, it MUST NOT be considered authenticated.
Is this really true? My understanding was that when proxy servers
thought clients were connecting they did not request client auth,
but rather used digest. Note that a number of clients react badly
when a cert is requested and they don't have one.
S 7.6.
A SIP registrar, acting as a server, follows the normative behavior
of Section 7.4. When it accepts a TLS connection from the client, it
present its certificate. Depending on the registrar policies, it may
challenge the client with HTTP Digest.
See above.
S 7.7.
Smae comment.
S 7.8.
The closest guidance in SIP today regarding certificates and virtual
SIP servers occurs in SIP Identity ([8], Section 13.4). The quoted
section states that, "... certificates have varying ways of
describing their subjects, and may indeed have multiple subjects,
especially in the 'virtual hosting' cases where multiple domains are
managed by a single application."
The above quote is incorrect, in that it implies that one certificate
can have multiple subjectAltName (or Subject) fields, each
corresponding to a discrete virtual server that represents a single
domain; actually, a PKIX-compliant certificate has exactly one
Subject field and at most one subjectAltName (the subjectAltName MAY
contain multiple identifiers for the Subject).
I'm not sure this is really contradictory, since it sort of puns on
the word "subject"...
S 7.8.
The TLS extended client hello [7] allows a TLS client to provide to
the TLS server the name of the server to which a connection is
desired. Thus, the server can present the correct certificate to
establish the TLS connection.
This seems like it should be a SHOULD.
S 8.
Authentication: each principal is authenticated to the other as
possessing a private key for which a certificate has been issued.
Moreover, this certificate has not been revoked, and is verifiable
by a certificate chain leading to a (locally configured) trust
anchor.
So, TLS doesn't guarantee any properties at all about the cert
validity. It just implies "do something PKIXy"
S 8.1.
I actually agree with this stuff, but I don't think it belongs here.
-Ekr
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
