Web Key Directory

[Bernhard Reiter]

Am Montag, 9. Mai 2016 21:50:59 schrieb Werner Koch:

> > == Where does the "/hu" come from?
>
> My guess is hashed user id.

Ok, where did you take it from?

> > == Update protocol, would TLS be better?
> >
> > The biggest discussion point I have is that of the update protocol. The
> > alternative to an email update would be to use an HTTPS based update.
> > This possibly would be as secure, but the roundtrip would be faster
>
> You mean to use a HTTPS based protocol for the update?  

Yes.

> This is not sufficient because the system works by
> asserting mail addresses - which 
> can only be done by sending mails.  Mails are not commonly send via an
> online protocol; but with the store-and-forward SMTP.

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 
account.

> 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?

> Basing the entire protocol on mail gives us queue management for free and
> allows the use of air gaps.

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
a very rare use case from my point of view. 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 also try to think about queue management advantages: Tt would be an 
advantage for server implementations right? As for the client, you cannot 
avoid getting emails in mixed order and it won't be many anyway.

> > and no automatic email sending and processing would need to be
> > implemented on both server and client sides.
> >
> > As drawback the HTTPS method technically depends on if the client
> > and server implementations have access to the email credentials of the
> > user in respect.
>
> The directroy and the update mechanism are independet of each other.
> This is why the update mechanism could also be used for DANE for
> OpenPGP.  

Yes, I agree that the management and the request part are seperate.

> > "directory" I don't like because there only one way to look up things
> > and I cannot discover new email addresses with it. "lookup" seems better
> > to me. "service" would address that we can also manage the public keys.
>
> Sorry, I do not understand this.  What we implement is indeed a
> directory of all public keys availabale for a given domain.

My point was to stress that it is not "browseable" in the name
and the distinguish it from "directory servers" like OpenLDAP
or "389 directory server".

Thanks for the explanations,
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/20160510/f0d521f4/attachment-0001.sig>