Web Key Directory

[Bernhard Reiter]

Am Donnerstag, 12. Mai 2016 09:47:59 schrieb Werner Koch:
> On Tue, 10 May 2016 09:40, bernhard at intevation.de said:
> > Ok, where did you take it from?
>
> *h*ashed *u*serid

Sorry I've missunderstood your previous statement here.

> > Being able to show the credentials to the mail service provider that
> > can access the email account (storage and settings) is equivalent from
> > the security point of view of being able to send and receive the emails
> > over this
>
> That mixes two entirely different services.  Web service may even be
> outsourced.

But it shows ownership of the email account.
With showing it by credentials it may save the crypto processing side
of the server to construct, safe and confirm a challenge. Otherwise
each server will need to implement this and while it may be ready available as 
Free Software from us, this may be a major implementation hurdle.

> >> Even if parts of the protocol would use HTTPS, there will in any case be
> >> a need to use SMTP/LMTP/IMAP/POP3 for the email confirmation.
> >
> > Why? To show that the client can do email format construction and
> > parsing?
>
> To receive and send confirmation mails ??

The alternative I am thinking of would not necessarily need confirmation 
emails. After a while I can request my own pubkey from the 
mail-service-provider and know that my status is okay then.

> > What security purpose are you thinking of with air gaps?
> > You mean in the case that your client is on a disconnected machine
> > and you transport emails over via removable medias? This seems to be
>
> Right , that is what an ari gap is about.
>
> > a very rare use case from my point of view. 

Do you agree that it is a rare use case?

If one out of 10.000 users has this issue, he will be of subset of 
archetype "Bob" (from https://wiki.gnupg.org/EasyGpg2016/VisionAndStories)
and we should probably not design for it. Bob could just use the WoT.

> > And it could be done with 
> > an https based protocol as well, just allow the challenge to be answered
> > with a reasonable time delay.
>
> I am not sure whether RFC-1149 like transport mechanisms [1] will work
> with TLS :-)

RFC-1149 with its addendum is a nice April Jokes (though it has been 
implemented, claims Wikipedia 
https://en.wikipedia.org/wiki/IP_over_Avian_Carriers) Did not know it yet. :)

Back to the serious issue:
The protocol can be designed in a way that if Bob wants to he can:
Take the challenge carry it over to a different machine, solve it there and 
then take it back and transmit back with TLS.

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160512/56964719/attachment.sig>