Subject: Re: [pkix] [ietf-smtp] [dane] Request DANE ALPS (another attempt to canonicalize local parts)

From: Wei Chuang <[email-masked]>
Date: Wed, 9 Mar 2016 14:15:50 -0800

On Wed, Mar 9, 2016 at 1:20 PM, John C Klensin <[email-masked]> wrote:

>
>
> --On Wednesday, March 09, 2016 21:46 +0100 John R Levine
> <[email-masked]> wrote:
>
> >...
> > As I said a few messages ago, it is not an accident or a
> > mistake that there is no canonical form for e-mail addresses.
> > We understand why some people wish it were otherwise, but the
> > number of ways that MTAs map e-mail addresses is only slightly
> > less than the number of MTAs, and the mappings are constantly
> > changing.
>

The alternative is that for each mapping i.e. email address variant
the sender will need a different set of signing keys and certificates,
which they will have to distribute.  Because these email addresss local
variations
have become so ingrained, adopting PKIX for email address authentication
becomes
burdensome to point of killing off its feasibility.  To quote pull a quote
from that
earlier message, I too worry that "perfect may be the enemy of the good"
here.

>
> And, while smaller than the number of mappings and MTAs, there
> are a very large number of specialized formats used for special
> purposes like extended tracking or managing of delivery and
> non-delivery notifications.  Having a canonical form that can be
> trusted requires understanding all of those cases, some
> deliberately undocumented, and then guessing correctly (every
> time) about what one is seeing.
>
> > It may be possible to figure out a way to use an SMTP server
> > or maybe a web server connected to an SMTP server as an
> > oracle, to ask do these two addresses deliver to the same
> > place or to ask for a key or a certificate for an address, but
> > even that is iffy.
>
> Or not, depending on _exactly_ how the operation and selection
> function are applied.  But the point is the only that server can
> definitively answer "do these deliver to the same place" and, as
> pointed out for one case below, even that information may not
> mean as much as people believe.
>
> > We can't even say what it means for two addresses to be "the
> > same". For example, on my MTA there about a thousand live
> > addresses that deliver to the same inbox where your message
> > was delivered, but that doesn't mean I want all of them to
> > have the same PGP or S/MIME keys.
>
> Nor does it mean that, by the time whatever you are using as an
> MUA or local mail routing rules (SIEVE or otherwise) that it
> will end up in  the same place ("inbox", "folder", etc.) on your
> desktop.
>
> In case it isn't clear, John Levine and I are in agreement about
> this and I'm writing only to emphasize his message and that his
> position is not unique to him.  The problem is really hard,
> changing every mail MTA and MUA in the word to match someone's
> idea of a desired canonical isn't feasible and probably would
> not be desirable even if it were, etc., etc.
>

Wouldn't the problem size be smaller, and limited to those that want to
validate
the identity of the sender and/or to do a key lookup?  At some future
point,
using PKIX asserted identities for sender and recipients for mail delivery
seems like
a good idea.

-Wei

> best,
>     john

---

From: Wei Chuang <[email-masked]>
Date: Wed, 9 Mar 2016 14:25:26 -0800

John C. and John R.:

Let me bring up a variation of email address naming that's much more
limited in scope.

Do you see any problems to introducing a new PKIX email address type to
support Unicode in email local part for
Email-Address-Internationalization?  This would be an alternative or
refined interpretation of rfc822Name in subject-alternative-name and
issuer-alternative-name PKIX extension.  As RFC6532 allows this, but
RFC5280 hasn't been updated to support this.

-Wei

---

From: Russ Housley <[email-masked]>
Date: Wed, 9 Mar 2016 19:12:15 -0500

The certificate name form specification seems very straightforward to me.  The hard part is the text that says how to compare the internationalized email address in the certificate to the one in the email message.

Russ

On Mar 9, 2016, at 5:25 PM, Wei Chuang wrote:

> John C. and John R.:
> 
> Let me bring up a variation of email address naming that's much more limited in scope.
> 
> Do you see any problems to introducing a new PKIX email address type to support Unicode in email local part for Email-Address-Internationalization?  This would be an alternative or refined interpretation of rfc822Name in subject-alternative-name and issuer-alternative-name PKIX extension.  As RFC6532 allows this, but RFC5280 hasn't been updated to support this.
> 
> -Wei  
> 
> On W ed, Mar 9, 2016 at 1:20 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> which they will have to distribute.  Because these email addresss local variations
> have become so ingrained, adopting PKIX for email address authentication becomes 
> burdensome to point of killing off its feasibility.  To quote pull a quote from that 
> earlier message, I too worry that "perfect may be the enemy of the good" here.  
>  
> 
> Wouldn't the problem size be smaller, and limited to those that want to validate 
> the identity of the sender and/or to do a key lookup?  At some future point, 
> using PKIX asserted identities for sender and recipients for mail delivery seems like
> a good idea.
>  
> -Wei
> 
> 
> best,
>     john
> 
> 
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Wei Chuang <[email-masked]>
Date: Thu, 10 Mar 2016 00:59:04 -0800

On Wed, Mar 9, 2016 at 4:12 PM, Russ Housley <[email-masked]> wrote:

> The certificate name form specification seems very straightforward to me.
>

Just trying to make sure there is consensus on what should be the "easy"
part, though one that I think will help quite a bit if it gets formalized.

> The hard part is the text that says how to compare the internationalized
> email address in the certificate to the one in the email message.
>

Agreed this is much harder.

-Wei

> support Unicode in email local part for Email-Address-Internationalization?
> This would be an alternative or refined interpretation of rfc822Name in
> subject-alternative-name and issuer-alternative-name PKIX extension.  As
> RFC6532 allows this, but RFC5280 hasn't been updated to support this.
>
> -Wei
>

---

From: Wei Chuang <[email-masked]>
Date: Thu, 10 Mar 2016 01:38:56 -0800

On Wed, Mar 9, 2016 at 3:08 PM, John R Levine <[email-masked]> wrote:

> No new problems, although it makes the variant local part issue even more
> obvious.  I don't claim to be a Unicode expert but it seems clear to me
> that for the mapping rules to be useful to non-technical users they have to
> match offline conventions, which means that they depend on the user's
> language.  So for a large system like gmail, there's likely to be dozens of
> different character mapping rules for different user languages, just as
> there are dozens of different language options for the gmail web interface.
>
> The alternative is that for each mapping i.e. email address variant the
>> sender will need a different set of signing keys and certificates,
>> variations have become so ingrained, adopting PKIX for email address
>> authentication becomes burdensome to point of killing off its feasibility.
>>
>
> S/MIME has been widely available for close to 20 years, implemented in
> nearly all desktop MUAs, and the number of people who use it (other than
> the ones whose employers demand it) still rounds to zero.  PGP is no
> better, despite the wide availablity of public PGP key servers.  I think
> the poor match between the addresses in certs and the ones in real mail is
> one of the reasons.
>
>
Very much agree.

> If you want to move ahead with this, it would be more productive to think
> harder about how to improve PKIX to match mail practice than try to force a
> billion mail users into the underdesigned PKIX address model since there
> are a whole lot more mail users than S/MIME and PKIX certificate users.
> It's not out of the question that SMTP servers could help, e.g., the oracle
> to ask if two addresses are the same recipient.
>

Agree that the SMTP servers could be a reasonable approach.  Others might
be to declare some sort of canonicalization rule or matching regex in the
cert.

>
> It'd also be a big help to clarify what the problem is to be solved. Is it
> to assert that mail with the address [email-masked] is from an
> actual person named Fred Smith, that encrypted mail will only be read by
> that person, that today's mail with that address is from the same person it
> was from yesterday, or something else?
>

I would argue in the basic guarantee users are looking for is an email
conversation between senders and receivers stays private, and that
participants don't get spoofed.  Using email addresses for naming would
suffice in this usage.  Its certainly true a validated personal name is
more meaningful to most users than a email address and really could help
with abuse prevention (anti phishing).  It does bring in a number of issues
though and certainly expands the scope quite a bit.  Validating Fred Smith
actually uses [email-masked] is going to be fairly difficult at
scale.  Doing this consistently across CAs is another issue though could
follow the model of EV server certificates i.e. create a policy ala CA/B
Forum for standardizing methods for proving ownership.  Another issue is
that personal names are often not unique and need some additional
identifier.  This too would need standardization most likely by some sort
of policy.  I'm sure there are other things to think about too.

-Wei

> R's,
> John

---

From: "John R Levine" <[email-masked]>
Date: 10 Mar 2016 11:28:16 +0100

> be to declare some sort of canonicalization rule or matching regex in the

Enumerating canonicalizations is hopeless for reasons already discussed, 
but Regex is an interesting idea, although it quickly takes you back to the 
question of what assertion the certificate is making.  At this point, the 
places signing S/MIME certs just check that the applicant reads mail at 
the address in the cert by sending it a link.  But what does that mean 
with a regex?  How do you check that the addresses it matches all 
map to the same mailbox?  Sometimes you can enumerate the addresses a 
regex matches (these are all me):

(hostmaster|johnl?)@(iecc|taugh)\.com

sometimes you can in principle but not in practice:

[Jj]\.?[Oo]\.?[Hh]\.?[Nn]\.?[Ll]\.[Ee]\.?[Vv]\.?[Ii]\.?[Nn]\.?[Ee]\.?@gmail\.com

sometimes you can't even try although you could use heuristics

(johnl?-[^@]+@iecc|[^@]+@johnlevine)\.com

but how do you allow those but not this one?

(hostmaster|johnl?)@(iecc|taugh|paypal)\.com

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Mar 2016 13:23:30 +0100

> (hostmaster|johnl?)@(iecc|taugh|paypal)\.com

The @ acts as a nice separator, no?

Eliot

---

From: "John R Levine" <[email-masked]>
Date: 10 Mar 2016 14:08:59 +0100

> The @ acts as a nice separator, no?

There's lots of ways to put multiple addresses in a regex.  How about 
these?

(jrlevine2|net.abuse)@yahoo.com
OPERAT[0O][email-masked]

An RE can match zillions of addresses, and other than in uninterestingly 
trivial cases, you can't test more than a tiny subset of them.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Thu, 10 Mar 2016 11:00:38 -0800

On Thu, Mar 10, 2016 at 2:28 AM, John R Levine <[email-masked]> wrote:

> places signing S/MIME certs just check that the applicant reads mail at the
> address in the cert by sending it a link.

Its certainly true that the issuer of a cert using such a regex represented
name matters greatly now.  (I wondered about the same issue in another
thread)  A third party CA is going to have a much harder time understanding
the local practices, and that represents a spoofing risk, though I suspect
it might be possible to communicate local practices to prevent that.  A
workable scenario is that the certificate issuer is the email domain owner
who understands intimately the email local practices.

-Wei

But what does that mean with a regex?  How do you check that the addresses
> it matches all map to the same mailbox?  Sometimes you can enumerate the
> addresses a regex matches (these are all me):
>
These are

---

From: "John R Levine" <[email-masked]>
Date: 10 Mar 2016 23:01:28 +0100

> who understands intimately the email local practices.

This is almost certainly a blind alley, and it'd help to back up and think 
about what problem you're trying to solve.

It seems to me that even though the same S/MIME certificate is used for 
signing and encryption, the two applications are quite different.

For signing, a random recipient having verified that the signature matches 
the message body wants to check that an address in the certificate matches 
the sender's address, typically the one on the From: line.  In my 
experience, even those of us with a zillion inbound addresses don't use 
all that many addresses for outbound mail, so it's practical to enumerate 
them all in certificates.  Or if a sender does want to make an address on 
the fly for which it does not yet have a certificate, if the CA is the 
sender's domain owner, it should be straightforward invent to ask the CA 
at that time for a certificate that matches the the address, and the CA 
can use whatever local rules it wants to decide whether the desired 
address is one that belongs to the requester and provide one or not. 
This is extra work, but in the context of mail submission, it's not an 
unreasonable amount of extra work.

For encryption of inbound mail, it doesn't matter what address is in the 
certificate; if the recipient can decode the message it's the right one, 
otherwise it's not.  So the sender can ask the domain's key oracle for a 
certficate for the address, the key oracle applies local rules and 
provides a certificate that might have the exact requested address, or 
might have another address that goes to the same recipient.

I'd think that something along these lines would not be particularly hard 
to implement, and would require semantic changes neither to PKIX nor to 
SMTP.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Mar 2016 16:20:14 -0500

best,
    john

---

From: "John R Levine" <[email-masked]>
Date: 10 Mar 2016 00:08:29 +0100

No new problems, although it makes the variant local part issue even more 
obvious.  I don't claim to be a Unicode expert but it seems clear to me 
that for the mapping rules to be useful to non-technical users they have 
to match offline conventions, which means that they depend on the user's 
language.  So for a large system like gmail, there's likely to be dozens 
of different character mapping rules for different user languages, just as 
there are dozens of different language options for the gmail web 
interface.

If you want to move ahead with this, it would be more productive to think 
harder about how to improve PKIX to match mail practice than try to force 
a billion mail users into the underdesigned PKIX address model since there 
are a whole lot more mail users than S/MIME and PKIX certificate users. 
It's not out of the question that SMTP servers could help, e.g., the 
oracle to ask if two addresses are the same recipient.

It'd also be a big help to clarify what the problem is to be solved. Is it 
to assert that mail with the address [email-masked] is from an 
actual person named Fred Smith, that encrypted mail will only be read by 
that person, that today's mail with that address is from the same person 
it was from yesterday, or something else?

R's,
John

---

From: [email-masked] (Martin Rex)
Date: Fri, 11 Mar 2016 18:19:27 +0100 (CET)

> the poor match between the addresses in certs and the ones in real mail is 

I've seen something called S/MIME in MUAs, but it is not even close to
what I would consider usable support for encryption & digital signatures
in EMail.  The original PGP, although it's not used more often,
at least doesn't suffer from obvious S/MIME fuckups.

What I've been seeing with S/MIME is several obvious total failures
 (1) in aspects of the protocol
 (2) in the MUA handling of archived digitally signed and encrypted mail
 (3) in the management of S/MIME certs (and S/MIME credentials)
     by both the public CAs signing these
 (4) in the management of S/MIME certs and trust by the MUAs

But the underlying fundamental problem is that PKIX only really
works for *online* authentication, and EMail implies archiving of
messages, and PKIX just sucks here and S/MIME is TITSUP about
archived EMails.

Several years go I received an S/MIME signed email from the car dealer&garage
about a maintenance issue with my car.  The signing certificate was
issued under a RootCA cert that was neither publicly available,
nor was it included in the S/MIME message (an S/MIME protocol defect).

It was simply impossible to make Outlook (2003 on WinXP 64-bit) verify
that S/MIME signature due to the lack of the RootCA cert.  Importing
and marking as trusted the intermediateCA cert (that was included in the
S/MIME message) or the end-entity cert (that was also included in the
S/MIME message) did not help a iota.

The obvious failures here are (1) why does S/MIME allow sending of
S/MIME message with cert _chains_ that are incomplete.  This is obvious
crap and should have been prohibited in S/MIME from the beginning.
The decision which cert from an X.509v3 cert path to trust, whether to use
"leap-of-faith" to establish this trust, and wether trust anchor
certs for the purpose are pulled from the message or distributed
out-of-band *MUST* be with the end-user.

Not being able to configure trust for this message to that signature
verification would succeed is TITSUP type (4) of the Outlook MUA.

I also have dozens of S/MIME-signed messages from colleagues sitting
in my EMail archives that are now being reported with "invalid signature",
but which verified just fine at some point in the past.  That is a total
failure of the (3) kind of the cert-signing CAs, plus a total failure
in (2) of the Outlook MUA in not timestamp-resigning received
digitally-signed mail before archiving it, so that digital signature
can still be verified in 20+ years.

Another issue is with encrypted EMail (one receives) and having to roll
one's own S/MIME keypair when the short-lived cert expires.  S/MIME MUAs
must either be prepared to properly handle dozens of prior S/MIME credentials
in order to access archived encrypted S/MIME messages, or they will have
to detach the encryption from the S/MIME-credential before message archival,
and re-encrypt the message with a key that will be long-term available.
The options for access of archived encrypted needs to be *standardized*
by S/MIME so that switching from one MUA to a different one will work
smoothly.  S/MIME is TITSUP in that area of archived encrypted EMail.

-Martin

*TITSUP = "Totally Incapable To Support Usual Performance" (theRegister)

---

From: Richard Clayton <[email-masked]>
Date: Fri, 11 Mar 2016 12:01:40 +0000

In message <[email-masked]>, John R Levine
<[email-masked]> writes

>In my 
>them all in certificates.

it's not uncommon to use destination specific addresses which are
invented in an ad hoc manner

     john+ietfsmtplist AT taugh.com

and there's a fair amount of support in MTAs for handling the replies
for this usage (although "+" is the de facto scheme; I've seen other
characters).

So you'd probably want some sort of wildcarding in the enumeration (and
that way of course lies madness [if we weren't there already])

>might have another address that goes to the same recipient.

one of the reasons that I like non-oracle non-automated schemes is that
I encrypt only some email (shock horror!) and so when I am about to send
a message to Fred and it is not encrypted then I realise I have the
wrong Fred ... and I re-consult my address book.  Oracles and automation
lead to perfectly secure messages on the wire being sent to totally the
wrong place (where they will be decrypted just fine) whether you
implement that in the MUA or by consulting MTAs.

viz: there's important human factors here.  Now if that's entirely out
of scope then automate away...

     If you think cryptography is the solution to your problem, then you
     don't understand cryptography and you don't understand your
     problem" - Roger Needham and Butler Lampson

- -- 
richard                                                  Richard Clayton

Those who would give up essential Liberty, to purchase a        Benjamin
little temporary Safety, deserve neither Liberty nor Safety.    Franklin

---

From: "John R Levine" <[email-masked]>
Date: 12 Mar 2016 10:46:42 +0100

>> I think the poor match between the addresses in certs and the ones in 
>> real mail is one of the reasons.

> at least doesn't suffer from obvious S/MIME fuckups. ...

Oh, I didn't say it was the *only* reason.

> one's own S/MIME keypair when the short-lived cert expires. ...

Finally this year there is a public S/MIME CA that will resign a 
certificatre rather than issuing a new one each year, but it's taken, 
what, 20 years?  This confirms your point and John K's that current MUA 
crypto is for the most part a checklist item, not something that most 
people would want to use.

R's,
John

PS: I'm using Alpine from macports.  There's been something broken in 
S/MIME signing for years, and nobody other than me (sort of) cares or even 
notices.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 12 Mar 2016 11:30:37 +0000

Hiya,

I think the subject has wandered and wanted to try to up level
this a bit to see if there's interest in tackling the general
problem...

On 12/03/16 09:46, John R Levine wrote:
> This confirms your point and John K's that current MUA

Yep, I think that's very true sadly, esp. for SMIME. A little
less so for PGP maybe, but both are IMO failures. (As were PEM
and MOSS before them.)

Even more sadly, I think the issues raised in this thread are
only a subset of the problems that need fixing if we are to
see ubiquitous use of e2e email security.

For example, issues not raised so far include: there is little
or no MUA development these days; both PGP and S/MIME were really
designed to only consider that the user has one MUA, which is
no longer true - fixing that requires new infrastructure (to
move or access private keys) which we've failed to do well at
least once; the email environment now is very centralised
compared to when PGP and S/MIME were designed, with the result
that unless enough of the really BIG players play, any proposal
is dead, and maybe the BIG service providers aren't incented to
improve the overall ecosystem and are more likely to want to
improve things for their own users; Mail header fields are not
protected which won't meet user expectations and protecting
those will cause a major tussle with anti-spam; and lastly for
now, e2e email security if widely deployed will force us to
change where we locate anti-spam and similar technologies.

And all of the above (plus the other issues already raised) are
each individually and independently killer arguments. So I'm not
hopeful frankly.

That said, I do think we should be encouraging folks who are
willing to try to move the needle, via experiments or otherwise.
And we should be liberal in judging those experiments, since
another conclusion I've reached after considering the above
issues is that if we ever do manage to get e2e working well
and deployed, then the technology we'll end up using will be
radically different from S/MIME or PGP (though it may well
have lineage from both). So even weird and wonderful experiments
that involve interoperability breakage should be encouraged
IMO, assuming they are sane.

We did btw, start a mailing list for this discussion a while
back. [1] That that didn't seem to get traction also seems to
re-enforce the impression that we're not yet in a place where
we'll be able to make significant progress on the overall here.
(Again, leading us back to encouraging experiments.)

Cheers,
S.

[1] https://www.ietf.org/mailman/listinfo/endymail

---

From: Wei Chuang <[email-masked]>
Date: Sun, 13 Mar 2016 08:58:11 -0700

On Thu, Mar 10, 2016 at 2:01 PM, John R Levine <[email-masked]> wrote:

> experience, even those of us with a zillion inbound addresses don't use all
> that many addresses for outbound mail, so it's practical to enumerate them
> all in certificates.

I agree with Richard that subaddressing remains an issue.

> Or if a sender does want to make an address on the fly for which it does
> not yet have a certificate, if the CA is the sender's domain owner, it
> should be straightforward invent to ask the CA at that time for a
> certificate that matches the the address, and the CA can use whatever local
> rules it wants to decide whether the desired address is one that belongs to
> the requester and provide one or not.

I would agree this could work but wanted to point out that generating
signing certs on demand could constrain the deployment of S/MIME to large
email providers that have resources to support being a CA due to possible
auditing, hardware HSM and the like requirements.

-Wei

> certficate for the address, the key oracle applies local rules and provides
> a certificate that might have the exact requested address, or might have
> another address that goes to the same recipient.
>

---

From: "John R Levine" <[email-masked]>
Date: 13 Mar 2016 16:06:00 +0000

> certificatre rather than issuing a new one each year, but it's taken, what,
> 20 years?  This confirms your point and John K's that current MUA crypto is
> for the most part a checklist item, not something that most people would
> want to use.
>
> ​Can you say more about this (possibly on the list)?

For a long time all of the free S/MIME cert signers force you to generate 
a new signing request in your browser.  Now Startssl gives you the option 
of uploading a S/MIME signing request, like you normally do for a web 
cert.

This requires that you understand openssl well enough to extract your 
current S/MIME public and private keys from your MUA or browser and turn 
them into a request packet, but I've done it and it works.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John R Levine" <[email-masked]>
Date: 13 Mar 2016 16:17:52 -0400

>> Finally this year there is a public S/MIME CA that will resign
>> a certificatre rather than issuing a new one each year, but
>> it's taken, what, 20 years?  This confirms your point and John
>> K's that current MUA crypto is for the most part a checklist
>> item, not something that most people would want to use.
>
> CACert, which has been around for a long time and will at least
> issue a new signed one with a new date without going through a
> lot of complex rituals.  However, they have their own set of
> issues and AFAICT, have never really gotten traction either.

There are plenty of places like Comodo that will give you a free S/MIME 
cert, but they all expire after a year and then you have to get a new one 
rather than renewing the old one.  So as someone noted, your cert store 
needs to have an ever growing set of expired certs so you can read your 
archived mail.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2016 20:25:00 -0000

>I agree with Richard that subaddressing remains an issue.

If so, we could probably come up with a constrained syntax to describe
subaddresses like 

 name <char> <string of chars> 

but you'd still need some way to call back
to the domain to ask whether that subaddress syntax was one it agreed
with.  Note there are plenty of mail systems like Yahoo that support
only a small number of subaddresses, like three per address.

>auditing, hardware HSM and the like requirements.

Naah.  For signatures from google.com, an HSM and an auditor makes
sense.  For the rest of us, we sign our DNSSEC zones with a python
script and would do the same for locally signed S/MIME certs.  The
only assertion you can make with a locally signed cert is "this is my
user" and in most cases that's not a particularly powerful assertion.

If you're going to do local signing, the reasonable way to publish the
signing cert is with DNSSEC as I suggest in draft-bhjl-x509-srv-00
section 5.  But with DNSSEC, the security is the security of one's
registrar accound, which is usually a user name and password.
Anything stronger than that down the line is security theater.

R's,
John

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 14 Mar 2016 13:05:41 +0000

I feel like all this discussion is missing the essential issue, i.e.: the CA certifies the address (effectively once relative to the # of emails) but it's the recipient has to do the match (on every message).  Sender MUA  configuration, on-demand certificates, etc.--these things don't address the real problem.

It also seems clear from this discussion how hard this problem is, because local-part usage is locally defined and therefore complex and unknowable.  We're all just guessing how local-part is used.  Because of this no attempt to canonicalize local-part or somehow signal in the certificate how matching is done is going to catch all the cases, or be able to mutate fast enough to keep up with problems.

It would be simpler, all things considered, to take a page from Johnny 2 and SSH and simply remove the problem.  IOW, it's time to punt.  ;)

I propose rewriting 5750 Sec 3 and deprecate the use of email addresses in S/MIME certificates *entirely*.  We'd add to Sec 3 instructions for MUAs to:

- Treat an email signature as a valid signature if the MUA has associated that signature's public key [1] with the From: or Sender: address.   Call this the "valid if expected" rule.

- Require the MUA to associate a public key with an email address the first time it receives a signed email, ideally with an explicit user acknowledgement.   The "record on first use" rule.

- Require MUAs to notify users of a security problem when an email from any address arrives with a signature by any other public key than the one expected.   The "notify on broken expectations" rule.

I'd also propose adding an optional procedure for key-rollover notification, by which the MUA will replace an existing association between and address and a public key, for example by defining a key-rollover message that's signed by both the old and key keys.  (This would be optional because it places requirements on sender PKIs that can't be met in all cases; e.g., my DoD PKI signing key is on a smartcard, and I lose access to old signing keys when a new signing key is issued.) 

A security note in Sec 5 would be needed to cover risks of and recommendations defend to against key introduction and key rollover attacks.  E.g., displaying the email address, cert Subject CN or DN, Issuer Subject CN, and possibly some interesting extensions (e.g., directory attributes, maybe private extensions, and the like) might provide context for the user decision.

This concept has the benefit of being conceptually simple, demonstrably secure, relatively intuitive (read Johnny 2, and plenty of user experience with key continuity management in SSH), backward-compatible, and future-proof.  In re: backward compatibility:  Sec 3 para 2 already requires MUAs to manage this case (supporting certs without an email address is a MUST)--this change simply makes it the primary rather than alternate case--so MUAs that conform to the new spec would be able to exchange S/MIME email with MUAs conformant to the old spec.   In re: future proofing, changes in certificate formats, extensions, email messaging specs, &etc. would have no impact.  It also makes the currently implicit S/MIME signaling path as explicit, removing ambiguity, which is a good thing.  Lastly, it lets the MUA provide meaningful automation--managing address books is something MUAs already do really really well.

This proposal still leaves the door open for common directories; e.g., the "Valid if expected" rule holds if the MUA consults a CA directory using the From: address, and the directory returns the public key that signed the email.

Email address matching can remain as an alternative, probably as a MAY clause, with associated warnings about making life harder for yourself.

-- T
[1] I'm intentionally using "public key" here because I think generalizing S/MIME to include PGP keying is a good idea, so we should get into the habit.  ;)

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Mar 2016 15:45:38 -0500

(Copying Stephen for reasons that will become clear if they are
not immediately obvious)

Folks,

I think there are three separate issues here and that it would
behoove us to try to keep them separate, especially if there is
any desire to make progress.  In no particular order:

(1) Is it reasonable to try to "canonicalize" email addresses to
make them more usable for purposes other than routing and
delivering email?  RFC 5321 and associated and predecessor
documents are fairly clear on the answer to that question: that
answer is "don't even consider it".  As discussions in this
thread and a recent DANE-related Last Call illustrate, even the
use of the term "canonicalization" dresses us and distorts some
of the actual issues: it may (note "may") be sensible to talk
about canonicalizing a mailbox local part by, e.g., lower-casing
a string that consists entirely of ASCII letters and digits but,
as soon as one starts dealing with strings containing non-ASCII
characters, the possibility of local parts that contain
substrings that are given special interpretation on the system
hosting the mailbox or MUAs that access its content, we aren't
really talking about canonicalization, we are talking about some
member of the "do what someone else means/intends" family.  As a
protocol, the first step in that one is "learn how to read
minds, including the minds of people you don't know".

If people want solutions for the "canonicalization" problem, I
suggest that it starts with trying to devise -- as part of the
email specs-- a profile for "modern" or "security-tool-friendly"
email addresses (and how they are interpreted) in the same
spirit as PRECIS and with a focus on "we aren't banning doing
anything else, but don't expect it to work with some
ever-broadening set of tools".  If that is to go anywhere, it
needs to recognize both the "locally-extended address" (aka
"subaddresses", etc.) ideas and similar issues which which the
IETF has never been willing to engage about, but maybe it is
time.  If it isn't, than anything that depends on guessing the
actual address given some surrogate for the address is both a
dead end and the source of risks of attacks.

(2) How bad MUAs are about handling signatures and encryption,
whether the design of one protocol or the other makes really
good implementations harder, and so on.  The IETF has
traditionally opted out of UI and other MUA interface issues
and, while I think that is usually a good decision, I think it
has led to some rather poor design in this case.  In addition,
we have all seen situations in which some feature has been
incorporated into a software package as a checklist item, i.e.,
because someone claimed that people in general, or a particular
customer, wouldn't buy the package unless some particular
feature was claimed to be present... or that having it present
on a list would be a competitive advantage.   For reasons that
are obvious, at least to anyone who has been around the industry
for a while, that situation often results in very poor
implementations that don't get fixed because, one the checkbox
is checked, no one cares.

Note that John Levine's "almost universally implemented, but
virtually zero use" comment is entirely consistent with the
symptoms of a checklist requirement.  

There are hard problems in that area, including the
(probably-correct) assumption by UI/ MUA developers that they
need to make things as simple and brainless as possible
(leading, among other things, to the assumption that keys should
be auto-selected to match (naively) email addresses) while those
who are more sophisticated about security issues may prefer to
go to the extra effort to hand-pick keys and use that process as
an extra check (see John Levine's recent note for a better and
more complete explanation of this).    I don't believe we know
how to get that balance right, but wish there were more
carefully-written and well-supported MUAs out there to use as
examples or try to get to make improvements.

(3) Whether the key structures are right for this sort of thing?
Even if one could deal with the two issues above, and even more
important if one partially cannot, or if you contact me and get
me to tell you how my email addresses are organized, one needs
to bind information to the keys (or certs) themselves that
provides details or rules that go beyond a simple list of one or
more addresses.  What John has been referring to as an Oracle
either exploits that information or substitutes for it.   The
ancillary information is important because, as we keep
rediscovering with the DNS, being able to look up a string and
find out that it is an alias for another string doesn't imply
being able to generate a complete list of names that are aliases
for some other name and because, not matter how much
standardization we do, we are not going to succeed in
establishing a single simple set of rules (like one
canonicalizing regular expression) for the entire Internet.

best,
    john

--On Friday, March 11, 2016 18:19 +0100 Martin Rex
<[email-masked]> wrote:

> John R Levine wrote:
>> 
>> S/MIME has been widely available for close to 20 years,
>> implemented in  nearly all desktop MUAs, and the number of
>> people who use it (other than  the ones whose employers
>> demand it) still rounds to zero.  PGP is no  better, despite
>> the wide availablity of public PGP key servers.  I think  the
>> poor match between the addresses in certs and the ones in
> I've seen something called S/MIME in MUAs, but it is not even
> close to what I would consider usable support for encryption &
> digital signatures in EMail.  The original PGP, although it's
> not used more often, at least doesn't suffer from obvious
> S/MIME fuckups.
> 
> 
> What I've been seeing with S/MIME is several obvious total
> failures  (1) in aspects of the protocol
>  (2) in the MUA handling of archived digitally signed and
> encrypted mail  (3) in the management of S/MIME certs (and
> S/MIME credentials)      by both the public CAs signing these
> works for *online* authentication, and EMail implies archiving
> of messages, and PKIX just sucks here and S/MIME is TITSUP
> about archived EMails.
> 
> 
> 
> Several years go I received an S/MIME signed email from the
> car dealer&garage about a maintenance issue with my car.  The
> signing certificate was issued under a RootCA cert that was
> neither publicly available, nor was it included in the S/MIME
> message (an S/MIME protocol defect).
> 
> It was simply impossible to make Outlook (2003 on WinXP
> 64-bit) verify that S/MIME signature due to the lack of the
> RootCA cert.  Importing and marking as trusted the
> intermediateCA cert (that was included in the S/MIME message)
> or the end-entity cert (that was also included in the S/MIME
> message) did not help a iota.
> 
> 
> The obvious failures here are (1) why does S/MIME allow
> sending of S/MIME message with cert _chains_ that are
> incomplete.  This is obvious crap and should have been
> prohibited in S/MIME from the beginning. The decision which
> cert from an X.509v3 cert path to trust, whether to use
> "leap-of-faith" to establish this trust, and wether trust
> anchor certs for the purpose are pulled from the message or
> distributed out-of-band *MUST* be with the end-user.
> 
> Not being able to configure trust for this message to that
> signature verification would succeed is TITSUP type (4) of the
> Outlook MUA.
> 
> 
> I also have dozens of S/MIME-signed messages from colleagues
> sitting in my EMail archives that are now being reported with
> "invalid signature", but which verified just fine at some
> point in the past.  That is a total failure of the (3) kind of
> the cert-signing CAs, plus a total failure in (2) of the
> Outlook MUA in not timestamp-resigning received
> digitally-signed mail before archiving it, so that digital
> signature can still be verified in 20+ years.
> 
> 
> Another issue is with encrypted EMail (one receives) and
> having to roll one's own S/MIME keypair when the short-lived
> cert expires.  S/MIME MUAs must either be prepared to properly
> handle dozens of prior S/MIME credentials in order to access
> archived encrypted S/MIME messages, or they will have to
> detach the encryption from the S/MIME-credential before
> message archival, and re-encrypt the message with a key that
> will be long-term available. The options for access of
> archived encrypted needs to be *standardized* by S/MIME so
> that switching from one MUA to a different one will work

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Mar 2016 13:44:39 -0400

--On Saturday, March 12, 2016 10:46 AM +0100 John R Levine
<[email-masked]> wrote:

>> cert expires. ...

    john

---

From: "John R Levine" <[email-masked]>
Date: 14 Mar 2016 12:34:52 -0400

TOFU certainly seems to work in practice.  But this does't address the 
question that started this discussion, looking for a new correspondent's 
certificate in a key store.  If I look for bobsmith@example and it has a 
cert for BobSmith@example, it's clearly the same person.  But if it finds 
Bob.Smith@example or Robert.Smith@example or R.W.Smith@example, who knows? 
That's why you need help from the mail system that knows where the 
addresses go.

> I propose rewriting 5750 Sec 3 and deprecate the use of email
addresses in S/MIME certificates *entirely*.  We'd add to Sec 3
instructions for MUAs to:

> - Treat an email signature as a valid signature if the MUA has
associated that signature's public key [1] with the From: or Sender:
address.  Call this the "valid if expected" rule.

> - Require the MUA to associate a public key with an email address
the first time it receives a signed email, ideally with an explicit
user acknowledgement.  The "record on first use" rule.

> - Require MUAs to notify users of a security problem when an email
from any address arrives with a signature by any other public key than
the one expected.  The "notify on broken expectations" rule.

Regards,

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 14 Mar 2016 20:00:12 +0000

> certificate in a key store.  If I look for bobsmith@example and it has a cert for
> BobSmith@example, it's clearly the same person.  But if it finds

The question that started the discussion is the inconsistency of MUAs to match local-part of a From: address to the local-part of an rfc822Address SANs or email RDN component  

However--An *a priori* search of a key store is a niche case.  

First, outside an enterprise there is no global directory, so there's no place to search anyway. You're much more likely to exchange unsigned emails first.

Second, inside an enterprise context where there *is* a directory, the address format is often fixed and known and the directory provides additional context (e.g., department, phone number, etc.) to disambiguate results, so strict matching standards aren't needed.

-- T

---

From: "John R Levine" <[email-masked]>
Date: 14 Mar 2016 16:40:35 -0400

> The question that started the discussion is the inconsistency of MUAs to 
> match local-part of a From: address to the local-part of an 
> rfc822Address SANs or email RDN component

That's one of them.

> However--An *a priori* search of a key store is a niche case.

If you will review at least a hundred recent messages on the ietf general 
list about draft-ietf-dane-openpgpkey, you will find that opinion is not 
universally shared.

> First, outside an enterprise there is no global directory, so there's no 
> place to search anyway. You're much more likely to exchange unsigned 
> emails first.

For PGP keys, there certainly is a global directory, albeit rather 
incomplete, and the draft I mentioned above purports to put such a 
directory into the DNS.

Regards,

---

From: Wei Chuang <[email-masked]>
Date: Tue, 15 Mar 2016 15:30:06 -0700

On Thu, Mar 10, 2016 at 2:01 PM, John R Levine <[email-masked]> wrote:

> all in certificates.  Or if a sender does want to make an address on the
> fly for which it does not yet have a certificate, if the CA is the sender's
> domain owner, it should be straightforward invent to ask the CA at that
> time for a certificate that matches the the address, and the CA can use
> whatever local rules it wants to decide whether the desired address is one
> that belongs to the requester and provide one or not. This is extra work,
> but in the context of mail submission, it's not an unreasonable amount of
> extra work.
>

Sorry about belaboring a point.  Popping out a level, what defines an
identity? even when we send mail to someone?  Is it a mailbox or rather an
authenticated user?  Most users probably would say they mean for their mail
to reach a person, and that the recipient would care about the person who
sent it.  How it gets there is almost invisible to them.  This probably
pedantic to many reading this, but doesn't RFC7542 specify a notion of a
Network Access Identity which has a notion of canonicalization for email
addresses?  Granted this is at the edge/client but the point is that is
separate from the authentication etc (AAA) service that consumes the
canonical NAI.  The analogy I'm try to draw is that the signature verifier
at the recipient MUA is an external entity to the SMTP, and is trying to do
a similar canonicalization for the purposes authentication.

-Wei

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 15 Mar 2016 16:21:08 -0700

From: pkix [mailto:[email-masked]] On Behalf Of Wei Chuang
Sent: Tuesday, March 15, 2016 3:30 PM
To: John R Levine <[email-masked]>
Cc: PKIX <[email-masked]>; ietf-smtp <[email-masked]>
Subject: Re: [pkix] [ietf-smtp] why you shouldn't even try to canonicalize local parts

On Thu, Mar 10, 2016 at 2:01 PM, John R Levine <[email-masked] <mailto:[email-masked]> > wrote:

This is almost certainly a blind alley, and it'd help to back up and think about what problem you're trying to solve.

It seems to me that even though the same S/MIME certificate is used for signing and encryption, the two applications are quite different.

For signing, a random recipient having verified that the signature matches the message body wants to check that an address in the certificate matches the sender's address, typically the one on the From: line.  In my experience, even those of us with a zillion inbound addresses don't use all that many addresses for outbound mail, so it's practical to enumerate them all in certificates.  Or if a sender does want to make an address on the fly for which it does not yet have a certificate, if the CA is the sender's domain owner, it should be straightforward invent to ask the CA at that time for a certificate that matches the the address, and the CA can use whatever local rules it wants to decide whether the desired address is one that belongs to the requester and provide one or not. This is extra work, but in the context of mail submission, it's not an unreasonable amount of extra work.

Sorry about belaboring a point.  Popping out a level, what defines an identity? even when we send mail to someone?  Is it a mailbox or rather an authenticated user?  Most users probably would say they mean for their mail to reach a person, and that the recipient would care about the person who sent it.  How it gets there is almost invisible to them.  This probably pedantic to many reading this, but doesn't RFC7542 specify a notion of a Network Access Identity which has a notion of canonicalization for email addresses?  Granted this is at the edge/client but the point is that is separate from the authentication etc (AAA) service that consumes the canonical NAI.  The analogy I'm try to draw is that the signature verifier at the recipient MUA is an external entity to the SMTP, and is trying to do a similar canonicalization for the purposes authentication.

DO NOT be misled by the fact that an email address and an NAI have the same overall structure.  They are not the same thing and they do not match each other except for on a local specific basis.   An NAI is expected to be normalized as far to the edge of a AAA system as is possible.  This generally means that the owner of the NAI (in terms of a person) is the one responsible for doing the normalization.   This allows for the internals of the system to do simple binary comparisons and ignore all of the issues involved.  It is never expected that a third party would create an NAI without lots of knowledge and input it into the system.  This is the same as I type my email address correctly into my MUI.  It says nothing about you being able to type my email address correctly into your MUI.

Jim

-Wei

For encryption of inbound mail, it doesn't matter what address is in the certificate; if the recipient can decode the message it's the right one, otherwise it's not.  So the sender can ask the domain's key oracle for a certficate for the address, the key oracle applies local rules and provides a certificate that might have the exact requested address, or might have another address that goes to the same recipient.

I'd think that something along these lines would not be particularly hard to implement, and would require semantic changes neither to PKIX nor to SMTP.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2016 19:41:39 -0400

> authenticated user?

My impression is that if you ask that question to three people, you'll get 
at least three answers, maybe more.  Maybe it's a mailbox, maybe it's a 
person, maybe it's something else.  I expect that the address 
"[email-masked]" goes to and from an identifiable group of people 
whose composition changes over time.  The useful definitions seem to be 
along the lines of "the same person or thing that sent/received mail last 
time" or "a name string vouched for by a mutually acceptable authority."

> addresses?

No.  NAIs deliberately look sort of like e-mail addresses but they are not 
e-mail addresses.  They're login tokens and serve a very different purpose 
than e-amil addresses do.

I realize that a lot of places use e-mail addresses as login tokens, but 
login tokens are stil different from addresses.  Every web site that wants 
an e-mail address from me to use as a login identifier gets a different 
address.  Mail sent to those addresses is delivered to the same mail 
sorting script, but I deliberately make the login tokens different.

Regards,

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 22 Mar 2016 12:41:27 +0000

> identity? even when we send mail to someone?  Is it a mailbox or 
> rather an authenticated user?  Most users probably would say they mean 
> for their mail to reach a person, and that the recipient would care 
> about the person who sent it.  How it gets there is almost invisible 
> to them.  This probably pedantic to many reading this, but doesn't 
> RFC7542 specify a notion of a Network Access Identity which has a notion of canonicalization for email addresses?
> Granted this is at the edge/client but the point is that is separate 
> from the authentication etc (AAA) service that consumes the canonical 
> NAI.  The analogy I'm try to draw is that the signature verifier at 
> the recipient MUA is an external entity to the SMTP, and is trying to 
> do a similar canonicalization for the purposes authentication.

It's more practical to treat the key as the relevant identity, since only the key holder can read the email irrespective of email address.  This is already implicit in most S/MIME aware MUAs--to decrypt, many MUAs simply of look for RecipientInfo's SKID in the user's private key store.  The RecipientInfo's issuerAndSerialNumer identifier are irrelevant.  IOW, if your key store allows it, you can delete the cert and retain the private key and decrypt S/MIME encrypted mail.  Or you can load your private key into *someone else's MUA* and read mail addressed to that key (it's convoluted to test this with, say, Outlook, but it can be done).  

This is on purpose, BTW, because there are plenty of relevant use cases where this is the only solution.  Expired certs, mailbox renaming, domain renaming (think mergers), & etc. would all interfere with accessing old encrypted mail if the cert had to be examined on decryption.

Keys matter.  Everything else is (potentially) transient, especially the association of key to mailbox.

-- T

---

From: Wei Chuang <[email-masked]>
Date: Tue, 22 Mar 2016 07:22:42 -0700

On Tue, Mar 22, 2016 at 5:41 AM, Miller, Timothy J. <[email-masked]>
wrote:

> It's more practical to treat the key as the relevant identity, since only
> the key holder can read the email irrespective of email address.  This is
> already implicit in most S/MIME aware MUAs--to decrypt, many MUAs simply of
> look for RecipientInfo's SKID in the user's private key store.  The
> RecipientInfo's issuerAndSerialNumer identifier are irrelevant.  IOW, if
> your key store allows it, you can delete the cert and retain the private
> key and decrypt S/MIME encrypted mail.  Or you can load your private key
> into *someone else's MUA* and read mail addressed to that key (it's
> convoluted to test this with, say, Outlook, but it can be done).
>
> This is on purpose, BTW, because there are plenty of relevant use cases
> where this is the only solution.  Expired certs, mailbox renaming, domain
> renaming (think mergers), & etc. would all interfere with accessing old
> encrypted mail if the cert had to be examined on decryption.
>

Thanks for the detailed explanation.  From this perspective a reasonable
refinement of RFC5751 would be to drop the verification of the FROM or
SENDER address?  Messages would still be signed by a CA issued
cert/private-key.  To make workable for people, the cert still ought to
specify either an email address, name or some other human comprehensible
identity (e.g. photo?) so that the recipient knows the cert belongs to the
sender.  The refinement would also need to address the issue of protecting
the integrity of the headers which the current comparison sort of does.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 22 Mar 2016 12:17:53 -0400

>> the key holder can read the email irrespective of email address.

For encrypted mail, this is clearly right.  For signed mail, it's not 
unreasonable but it's also less clear.  The whole issue of binding real 
world identities to e-mail addresses is a swamp, not one that I think we 
are any better at draining than anyone else.  For PGP, there's the web of 
trust which is supposed to help you decide whether a key matches a person, 
but doesn't really say anything about the e-mail addresses attached to the 
key.  For S/MIME the CA does what it does, which these days is rarely any 
more than a challenge message to the e-mail address.

So I mostly agree with you, with the caveat that you have to be careful 
not to misinterpret assurances about an e-mail address as assurances 
about the person or entity allegedly associated with that address.

Regards,

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 22 Mar 2016 18:29:42 +0000

> SENDER address?  Messages would still be signed by a CA issued cert/private-
> key.  

This is already present in 5750.  See Sec 3--MUAs MUST be able to handle certs without an email address, and there's a SHOULD for optional processing when there's a mismatch.  I proposed in one of these thread forks that we could update 5750 by making the "match" requirement a MAY/OPTIONAL and maybe explicitly deprecate its use (though deprecation might wait for a further future update), and promote the alternate processing to a MUST.

That's the smallest possible change and preserves compatibility (any MUA that *can't* handle a cert w/o RFC822 address or provide alternate processing for a mismatch is already non-conformant).

I'd also think it wise to expand on client behavior a bit in re: making associations between keys and addresses, but I wouldn't want implementers to take recommendations as gospel, so they probably belong in an Appendix or in Security Considerations.

> To make workable for people, the cert still ought to specify either an
> email address, name or some other human comprehensible identity (e.g.
> photo?) so that the recipient knows the cert belongs to the sender.

This is all stuff that at best belongs in an appendix, at best.  Personally I wouldn't want to go beyond the known security risks of handling first use or when a key is changed.  I'd like to see what implementers can come up with on their own and am reluctant to constrain future solutions.

>								  The
> refinement would also need to address the issue of protecting the integrity
> of the headers which the current comparison sort of does.

The matching requirement does nothing of the sort, but I take your meaning.  I've never been completely clear on why S/MIME signatures don't cover headers.  There may be a damn good reason.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 22 Mar 2016 18:43:38 +0000

> For encrypted mail, this is clearly right.  For signed mail, it's not unreasonable
> but it's also less clear.  The whole issue of binding real world identities to e-
> mail addresses is a swamp, not one that I think we are any better at draining
> than anyone else.  For PGP, there's the web of trust which is supposed to
> help you decide whether a key matches a person, but doesn't really say
> anything about the e-mail addresses attached to the key.  For S/MIME the
> CA does what it does, which these days is rarely any more than a challenge
> message to the e-mail address.
> 
> So I mostly agree with you, with the caveat that you have to be careful not to
> misinterpret assurances about an e-mail address as assurances about the
> person or entity allegedly associated with that address.

What I loved about SPKI/SDSI was the idea of namespaces and namespace chaining.  "The key that Alice nicknamed 'Bob's key'" is unambiguous and implementable.  Once I've named a key, a computer can track that name across multiple different identifiers effortlessly.  Once I tell the computer that *this specific key* represents "Alice from the Home Office," Alice can use any address--indeed, any protocol that allows her to sign messages--and my computer can tell me it's Alice from the Home Office.

No complex web of trust, no CAs.  If I were implementing, I'd be straight up stealing this.

Yes, a priori discovery in a morass of SPKI/SDSI certificates is a right royal PITA, but you can't have everything.  But then again, maybe we don't actually have that problem.  It's all in how you think about the issue.

---

From: "John R Levine" <[email-masked]>
Date: 22 Mar 2016 16:44:33 -0400

> What I loved about SPKI/SDSI was the idea of namespaces and namespace 
> chaining.  "The key that Alice nicknamed 'Bob's key'" is unambiguous and 
> implementable.  Once I've named a key, a computer can track that name 
> across multiple different identifiers effortlessly.  Once I tell the 
> computer that *this specific key* represents "Alice from the Home 
> Office," Alice can use any address--indeed, any protocol that allows her 
> to sign messages--and my computer can tell me it's Alice from the Home 
> Office.

I agree, that's about the best we can hope for.  Too bad nobody does that.

Regards,