Subject: Meet in Paris?

From: Derek Atkins <[email-masked]>
Date: Tue, 05 Jul 2005 15:16:20 -0400

Hi,

Do the members of this working group feel we need a meeting
in Paris?  I think we might want to meet in order to consider
work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
that's been proposed).

If you feel strongly that we either should or should not meet
in Paris, please let me know.

If you have a non-2440bis work item that you'd like (Ben: This is
a hint to you) please let me know how much time you'd like on
the agenda to discuss your new work items.

Thanks,

-derek, your friendly neighborhood chair
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Ben Laurie <[email-masked]>
Date: Sat, 09 Jul 2005 12:31:28 +0100

> the agenda to discuss your new work items.

Unfortunately, IETF decided to schedule up against USENIX Security, so 
I'll be in Baltimore, not Paris.

Cheers,

Ben.

-- 
 >>>ApacheCon Europe<<<                   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Jul 2005 10:31:06 +0200

> work beyond 2440bis (e.g. PFS, Mail-Headers, or other work

I would likely be around to talk about the OpenPGP mail header [1], if
there is interest.  Feedback from OpenPGP experts on the usefulness of
adding a "supports" token to the header is one open issue that may be
useful to discuss.

I'd hate to see anything slow down 2440bis further though.

[1] http://josefsson.org/openpgp-header/

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jul 2005 13:34:04 +0200

> adding a "supports" token to the header is one open issue that may be

I actually am more in it for just specifying where the keyserver for
this key is located. Or actually just having the address of this key.

Eg, when I send mail out, it gets signed by my [email-masked] key. But
there is no reference to that anywhere to which id which key belongs
(afaik).

Currently a raw mail contains something like:
8<-----------------------------------------------------------------
--=-Zzt3A5Tzpnkf1gPDBX5s
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

----------------------------------------------------------------->8

What if we added, in addition to the "Comment:" line a line like:
8<-----------------------------------------------------------------
User-ID: [email-masked]
----------------------------------------------------------------->8

We then know, programmatically, who this key is supposed to represent.
We can then:

8<-----------------------------------
$ dig +short _pgpkey._service.unfix.org any
_pgpkey-http._tcp.unfix.org.
_pgpkey-https._tcp.unfix.org.
----------------------------------->8
PTR records

8<-----------------------------------
$ dig +short _pgpkey-http._tcp.unfix.org. any
"path=/pks/"
42 100 80 purgatory.unfix.org.
$ dig +short _pgpkey-https._tcp.unfix.org. any
"path=/pks/"
13 100 443 purgatory.unfix.org.
----------------------------------->8
TXT + SRV record.

https having the weight, from which we can construct:
https://purgatory.unfix.org/pks/

where a onak cgi is located, basically doing hkp, but then over full
https. (one can also do _pgpkey-hkp for hkp://.... but I don't have a
hkp server on that box, so it is not in DNS)

We then know:
 - if DNSSEC would be deployed we for sure would know
   the dns answer was valid and that the above servers
   are authoritive keyservers for the unfix.org domain.
   But we can assume this is pretty correct even without dnssec.
 - ssl on the https + the certifacate make sure we
   are talking to the correct box.
 - the user was able to put his key on the keyserver
   running for this domain

Then we can assume:
 - when we do a https://purgatory.unfix.org/pks/lookup/[email-masked]
   that they key returned is valid for this ID.

We can now verify it, giving it some extra 'trust points' because the
domain said this key belongs to it. Or we could require that keyservers
used in this way make sure all the keys get signed by the operator, who
has a key in the strong set. eg large ISP's could automatically generate
keys for their users and sign outgoing mail based on SMTP AUTH, to avoid
people having to do pgp themselves.

Another verification could be comparing that the 'home keyserver', as
found in the key itself, 

This brings us distributed keyservers.
Though one still requires to have a lot of keys in a local cache, which
at a certain point most likely is at least 60% of the keys.

Having this field also allows one to specify a nice policy for email, eg
in a SPF record: "pgp:unfix.org", saying that mail send from this domain
has to be signed with a key which has a user-id in unfix.org.

/me now expects an avalanche of comments about many things I did not
take into the sum of the equation ;)

Greets,
 Jeroen

---

From: Jon Callas <[email-masked]>
Date: Fri, 15 Jul 2005 16:17:49 -0700

I'm going to be in Paris. A meeting is just fine.

I want us to go to last call on this, and discuss other things like 
compatibility bakeoffs, etc.

	Jon

---

From: Derek Atkins <[email-masked]>
Date: Mon, 25 Jul 2005 20:47:57 -0400

I'd be happy to put you on for 5-10 minutes?  I really don't
think it will slow down 2440bis.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Mon, 25 Jul 2005 20:47:10 -0400

Ben,

Any chance you could send a surrogate to present?  I think it
would be very useful if someone could stand up for 5-10 minutes
and describe your PFS proposal.

-derek

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Jul 2005 10:01:54 +0200

Sure!  I can raise the open issues and invite more feedback.

Thanks,
Simon