Web Key Directory
bernhard at intevation.de
Thu May 12 14:37:46 CEST 2016
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
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  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.
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...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel