ietf
[Top] [All Lists]

RE: Review of draft-saintandre-tls-server-id-check

2010-08-30 18:10:34
Peter St. Andre said:

"an SRV record can be used for two quite different purposes:

1. To point from an application service name to a particular host/domain name 
in the same administrative domain (e.g., _imap._example.com points to 
mailhost.example.com for its IMAP service).

2. To delegate an application service name to a hosting provider outside in the 
administrative domain of the application service (e.g., example.com delegates 
its IMAP service to apps.example.net).....

As I see it, RFC 4985 glosses over the foregoing distinction."

[BA] It took some adjustment for me, but as I understand it, the underlying 
assumption of RFC 4985 is that if the certificate is considered valid by RFC 
5280 path validation (e.g. chains to a valid trust anchor, etc.) then 
delegations both within and outside the source administrative domain can be 
validated. This logic, if pursued, could apply beyond SRV RR validation, to 
things like NAPTR validation via a URI/IRI in the certificate.

Scoping (EKUs, name constraints, etc.) is a different question.

Peter also said:

"However, the question arises: what is the client supposed to check if an
SRV lookup for _imap._example.com yields apps.example.net? My reading of
RFC 4985 leads me to think that the certificate presented by
apps.example.net is supposed to contain an SRV-ID of _imap.example.com,
which means roughly "this certificate indicates that this provider is
authorized to provide IMAP service for the example.com domain". (How the
certification authority determines that the delegation is indeed
authorized is outside the scope of this I-D.)

[BA] That's also my reading of RFC 4985, but I'll let others more knowledgeable 
(like the author) weigh in.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>