Re: [webfinger] [art] Auto-configuring Email Clients via WebFinger

[Phillip Hallam-Baker <[e-mail]>]

Responding to Paul's point about his wife needing a country specific
configuration, I think we need to think about this a bit differently.

This is one example of an application configuration problem and a service
discovery problem. What we need here is a scheme that is capable of
supporting the general case.

It makes no sense for any of the providers to change their existing schemes
unless it is to move to a scheme that is more powerful because it is more
general. Which means that at minimum it is supported by all the MUAs but
ideally means it is supported by multiple applications as well.

I have been thinking about this problem from the other side. I started what
is now the Mathematical Mesh trying to work out how to automatically
configure and maintain S/MIME and OpenPGP. While doing that, I suddenly
realized that I could add in the SMTP configuration as well. So once Alice
has configured her email service on one device, it is configured for them
all. She will get her SUBMIT/IMAP/POP3 settings at the same time that she
gets the S/MIME and OpenPGP keys to work on the device. I showed this to
Dave Clark who asked for SSH as well (which is a real pig to configure as
there is a bootstrap problem and a foul up may require someone to take a
plane trip to a server to fix it).

Being able to replicate the config across devices does not solve the
problem of initial acquisition of course. But the replication mechanism
should certainly use the same data structure (though translated to JSON
probably).


I have not thought about the Enterprise application of the Mesh in detail
yet because I have to get it working for individual users first. But I am
pretty sure that what we want here is single point onboarding (and
terminations).

So Alice joins example.com. She is issued a (new) company laptop and BYOB's
her mobile.

The onboarder checks the boxes for the corporate applications she is
authorized for, email, ssh, etc. and the group encryption services for the
teams she belongs to. The configulator then does all the rest.

All that remains is to connect up Alice and her devices to these
configurations. Which can be done in person via QR code or remotely via a
Base32 fingerprint. It presents a workfactor of at least 2^112 either way.

So from Alice's point of view, when she goes to the badge office to pick up
her badge, she scans a QR code with her phone and that is it - she is all
configured for email, chat, slack, slick, ssh, S/MIME and all the encrypted
data she needs from the cloud. If she is working on some really sensitive
stuff, her line manager or a VP might need to meet her in person to
authorize adding her to certain groups.

Termination should mean no more than unchecking the boxes.


The cryptography I am using was discovered by Torben Pedersen and Matt
Blaze in the mid 1990s. The reason it hasn't been applied was that it was
too hard to use and until Robert Snowden came along, people thought the
administrator of the key service in the cloud could be trusted. So I have
made it really easy to use and administrate even in the case that we have
separation of duties at the administrator level as well.


On Thu, Jul 18, 2019 at 10:12 AM Paul E. Jones <paulej=
[e-mail]> wrote:

> Dave,
>
> RFC 6186 is the DNS-based one to which I referred below. Unfortunately, it
> doesn't allow setting various configuration options and wouldn't work at
> all for my wife's use case where employees use different mail servers based
> on the country in which they reside.
>
> Paul
>
> ------------------------------
> *From:* Dave Cridland <[e-mail]>
> *Sent:* July 18, 2019 4:40:41 AM EDT
> *To:* "Paul E. Jones" <[e-mail]>
> *Cc:* "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject:* Re: [art] Auto-configuring Email Clients via WebFinger
>
> Obviously I'd prefer ACAP.
>
> But also, please note the existence of RFC 6186. It's not widely deployed,
> but if we were to open this can of worms, and not simply reuse
> Thunderbird's autoconfig XML format (which, if I recall, is also supported
> by various other Open Source MUAs), then I'd be keen to get SRV up and
> running properly.
>
> Dave.
>
> On Mon, 15 Jul 2019 at 20:31, Paul E. Jones <paulej=
> [e-mail]> wrote:
>
>> ART folks,
>>
>> Several years ago when I was working on WebFinger, one of the use cases I
>> presented was using WebFinger to facilitate auto-configuring email
>> clients.  It was and still is a problem I deal with today.
>>
>> For my own family, I have to manually configure several different clients
>> on several different platforms for each member of the family.  It's time
>> consuming and really needs to be made simpler.
>>
>> My wife also has to deal with this issue where she works, because her
>> company, while just 100 or so employees, has offices in two different
>> countries and the mail server settings an employee uses depends on his or
>> her geographic location.  To use standard IETF protocols, it means a lot of
>> manual provisioning.
>>
>> I see the same sort of challenges with service providers. If one wants to
>> have his or her own domain, but isn't technically savvy, they're in for a
>> lot of "fun" trying to figure out the various settings. Seriously, no
>> normal person should have to understand what SMTP or IMAP means, and
>> definitely what port numbers or security settings to fill in.
>>
>> While there has been a generic DNS-based method for email provision for a
>> while, it doesn't work for me. It doesn't work for my wife's company,
>> either. It also doesn't define everything one might need to define (e.g.,
>> required security settings or policies).
>>
>> So we put together a very simple example to show how this might be done
>> with WebFinger.  See the draft here:
>> https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00
>>
>> The example in that document should make it clear how we intend this to
>> work, though the detailed procedures and syntax are missing.  We first want
>> to see what interest exists and if this general approach will work for
>> everyone before getting into too much detail.
>>
>> We'd love to have some dialog on this to see how we can address this
>> problem of auto-configuring email clients.
>>
>> Paul
>>
>> _______________________________________________
>> art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/art
>>
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art
>