On Tue, Apr 23, 2013 at 12:33 PM, Hannes Tschofenig
<[email protected]> wrote:
> "TLS over OpenPGP" sounds a bit strange. I looked at your blog post and it
> seems that you have implemented RFC 6091, which allows OpenPGP certificates
> to be used instead of X.509 certificates within the TLS handshake.
>

Yes, actually a more correct definition would be "OpenPGP over TLS",
but "over" not as in tunneled or wrapped, but as in authenticated
using OpenPGP certificates :-)

> I am curious how you use the OpenPGP certificates: do you use them for
> server-side authentication and, if so, how do you validate the certs?
>

Yes I use them for authentication. In my case, I just need to verify
if one or more signatures are present on the client's public key
(signature that a server can recognize as valid). After that,
server iterates through all certificate uids, searching for a special
"token" on the comment field (e.g. "kontalk" or something like that,
maybe "xmpp" or "jabber" or "jabber|domain.com", maybe we could define
a XEP for that? [2]); the e-mail field will be the client's Jabber ID (of
course verifications to the e-mail field are made too just in case [1]). I
still have to find a use for the name field... I guess it can be used
as a "public name", since jabber IDs in my case are a bit "hard to
remember" (<sha1 hash>@kontalk.net).

> Ciao
> Hannes
>
> PS: You might also be interested to take a look at:
> http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07
>
> It adds the use of raw public keys.
>

Out of band? Meaning it uses another channel for certificate
verification? I don't fully understand...


[1] actually the current implementation (as of today) just takes the
e-mail field from the first uid, I'm implementing the other checks
right now.
[2] actually XEP-0178 already has that: <auth/> element can be filled
with the jabber id a client wants to authenticate with - of course
server will decide if it's allowed or not. So I guess the comment
field is useless afterall :-)

-- 
Daniele

Reply via email to