--On Friday, April 22, 2016 10:26 -0700 Wei Chuang
<weihaw(_at_)google(_dot_)com> wrote:
Regarding the suitability of embedding email addresses in
certificates, would it be fair to say that domains willing to
live with permanent email identities and narrowly defined
delivery patterns could have a standardized means of
describing equivalent email addresses? Then recipients of
emails with such certificates could then validate the sender
using a modified RFC5280 validation. Issuers of such
certificates would have to insure that the domain meets those
requirements, and those that don't could be issued
certificates that fall back to current RFC5280 behavior.
I don't know how to answer your question, so let me answer a
slightly different one, perhaps agreeing (again) with the
comment Alexey made.
First of all, a certificate issuer can put whatever it likes
into the certificate, including strings that look like email
addresses. Whether such strings are actually email addresses,
how multiple of them relate, whether the binding between such a
purported email address and a mailbox is actually valid, and
whether the address and/or mailbox actually are under the
control of some particular person are really trust model
questions.
To be clear, I could say almost the same things about, e.g., an
identifier consisting of a hash of height, weight, and birthdate
or some sequentially-assigned personal ID. The question really
does not have a lot to do directly with email or email protocols.
Now, because it is a trust model question, or several of them, I
think the community should try to insist that the certifier be
very clear about what the relationships are that they are
certifying. In today's environment, that could be a BCP-like
statement to the effect that certifiers who don't supply
information about what they are attesting to and/or who assert
that they are not attesting to anything (or anything other than
ability to pay a bill) should be ignored for most purposes, but
that still isn't an email problem.
Partially on the basis of the old principle that chains are no
stronger than their weakest links, similar comments apply to
anything in which the DNS is involved. So, however you would
rank your trust relationships in the following cases:
o joebloggs(_at_)example(_dot_)com, where the Whois (registry
information) record indicates that the ownership for
example.com is hidden for privacy reasons and you don't
get to find out who the registrant is.
o johndoe(_at_)example(_dot_)net, where data show apparently-good
contact information but the registrar has an established
reputation for doing business with evildoers and
allowing registrants (possibly just by aggressive
non-checking) to lie about actual contact or ownership
information.
o johnbloggs(_at_)criminals-are-us(_dot_)org and/or
johnbloggs@mafia., with the obvious implications even
though the upstanding businessmen and community members
involved are clearly identified.
Now, my answers about those cases (and others) and yours may not
be the same. That is what trust models are all about. On the
other hand, if you are going to do something automated
--something that essentially tells users who and what they
should trust-- I'd hope you would be very thoughtful and open
about those decisions and how you make them.
But, again, this really has very little to do with email beyond
string similarity and some questions about the stability and
reliability of various bindings.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp