On 8/30/10 5:10 PM, Bernard Aboba wrote:
> 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.

If that's the logic, I'd at the least like to see a "4985bis" spec make
that clear, because IMHO it's not spelled out now.

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

Agreed.

> 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.

That would indeed be helpful.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to