On 9/13/10 10:52 AM, Shumon Huque wrote:
On Mon, Sep 13, 2010 at 10:08:11AM -0600, Peter Saint-Andre wrote:
On 9/9/10 12:22 PM, Shumon Huque wrote:
On Wed, Sep 08, 2010 at 11:08:29PM +0200, Stefan Santesson wrote:
The only thing the client need to do is to verify that the domain name
provided in the input to the lookup matches the host names provided in the
output. It can then safely use the host names in the SRV record as
reference
identifiers IF the SRV-ID in the server certificate matches the the
reference identifier.
This only works if the certificate matching rules say something
like "match the SRVName AND also match the DNS resolved target
hostname in dNSName". If a client attempts to match _only_ the DNS
resolved hostname without DNSSEC, there is a security problem.
The question is: what should the certificate matching rules say
when encountering a certificate with multiple identity types?
Right now the draft approximately says "find a match" (ie. find
ANY match), rather than match some logically AND'ed combination of
identity types.
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#section-4
Hi Shumon,
As I see it, this I-D is attempting to capture best current practices
regarding the issuance and checking of certificates containing
application server identities.
Yes, but whether they are actually "current" best practices is
debatable. I certainly would like them to become best practices.
For example I don't believe any existing commercial CAs issue
certificates with the SRVName or URI SAN name forms.
As far as I know, at least one CA will issue certificates with the
SRVName form (for XMPP certificates). We could ask some folks in the SIP
community if any CAs issue certificates with the URI form (see
draft-ietf-sip-certs).
Do we have evidence that any existing
certification authorities issue certificates containing both an SRVname
for the source domain (e.g., example.com) and dNSName for the target
domain (e.g., apphosting.example.net)? Do we have evidence that any
existing application clients perform such checks? If not, I would
consider such complications to be out of scope for this I-D.
I think the question is whether we have examples of applications
that need to verify "combinations" of subjectaltname name forms in
certificates. Stefan says there are, but so far no-one has offered
up any public specifications of such apps. So, I think until we
have them, I agree we can defer considerations of them to future
documents.
Agreed. I've never seen this I-D as the final word, but instead as the
beginning of a longer-term conversation, both about the limited topic
that's covered in the I-D as well as all the topics we deemed out of scope.
I think it's reasonable for this draft to consider multiple identity
types in certificates (eg. common name, dNSName, SRVName) with the
current matching rules of ANY. This might be needed to gradually
transition an app from validating a host specific identity to an
application specific identity. The current draft allows this.
Correct.
That said, we need to be aware that if such usage arises in the future,
someone might write a document that updates or obsoletes this I-D; in
fact the present authors very much expect that such documents will
emerge after the Internet community (specifically certification
authorities, application service providers, and application client
developers) have gained more experience with PKIX certificates in the
context of various application technologies.
Sounds reasonable.
I'm looking forward to further work in this area.
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf