On Sun, Mar 22, 2015 at 03:12:31PM +0000, Alexey Melnikov wrote:
> On 21/03/2015 07:38, Viktor Dukhovni wrote:
> >On Thu, Mar 19, 2015 at 12:06:13PM +0100, Leif Johansson wrote:
> >
> >>We need to get this document out the door! Getting a few reviews would
> >>help a great deal!
> >Overall the document is in good shape.
> >
> > In section 3 a sentence is truncated:
> >
> > 3. URI-ID identifier type (subjectAltName of
> > uniformResourceIdentifier type [RFC5280]) MUST NOT be used by
> > clients for server verification, as
>
> Thank you, I will fix. The rest of the sentence was commented out for some
> unknown to me reason.
I have a couple of questions about SRVNAME.
1. Which TLS libraries implement support for SRVNAME, beyond
any generic support for generic "other name"? In other
words, is vefication of SRVNAME likely to be easily available
to applications now, or will application developers have to
wait for TLS library developers to add support for this?
A quick look at OpenSSL shows no support for SRVNAME.
2. MTAs are sometimes configured to act as submission clients.
Most frequently on single-user machines. When should such
an MTA use an SRVNAME reference identifier for the target
SMTP server? To clarify, a typical configuration might be:
relayhost = [smtp.example.net]:587
or less frequently indirection via /etc/services:
relayhost = [smtp.example.net]:submission
thus in current practice often no explicit indication that
the service is "submission" (could just be a private peering
relay that happens to use port 587) and no explicit SRV
lookup of "_submission".
When should such an MTA choose to accept an SRVNAME of
"_submission.smtp.example.com" in the peer's certificate?
Would that only be applicable if new code is written to
support SRV indirection? Should use of "_submission"
SRVNAMES be inferred from the target port? Or enabled via
per-destination configuration?
[ I know that the document is not about MTA-to-MTA, but
I think the intention there is to exempt forward-path
port 25 relaying, and not necessarily "stub" MTAs that
try to emulate user agents. ]
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
