Subject: Please review OpenPGP part of RFC 2538bis

From: Simon Josefsson <[email-masked]>
Date: Sat, 06 Nov 2004 19:48:31 +0100

All,

RFC 2538 is being revised to improve the details regarding OpenPGP
certificates, to promote interoperability.  The point of the document
is to store OpenPGP certificates and revocation information in DNS.  I
would appreciate if people here would look at the proposed update to
see if it reference RFC 2440 properly.  The document is available
from:

http://www.ietf.org/internet-drafts/draft-josefsson-rfc2538bis-00.txt

In particular, the part that describe what goes into the data portion
of OpenPGP CERT RRs now reads:

   The PGP type indicates an OpenPGP data packet.  Two uses are to
   transfer public key material and revocation signatures.  The data is
   binary, and MUST NOT be encoded into an ASCII armor.  Public keys can
   use the OpenPGP public key packet (tag 6) or public subkey packet
   (tag 14), as described in section 5.5 of [5].  Revocation signatures
   can use an OpenPGP signature packet with a revocation signature type,
   i.e., signature type 0x20, 0x28 or 0x30, as described in section 5.2
   of [5].

Is this correct?  Would it be useful to mention other kind of OpenPGP
data packets directly, as well?

The owner name guidelines part of the document has been extended with
the following text.  To review this require some familiarity with DNS.

   Applications that receive an OpenPGP packet but do not know the email
   address of the sender will have difficulties guessing the correct
   owner name.  However, the OpenPGP packet typically contain the Key ID
   of the key.  Such applications can derive the owner name from the Key
   ID using an Base 16 encoding [8].  For example:

      $ORIGIN example.org.
      F835EDA21E94B565716F    IN CERT PGP ...
      B565716F                IN CNAME F835EDA21E94B565716F

   Again, if the same key material is stored at several owner names,
   using CNAME can be used to avoid data duplication.

Further, if someone has additional thoughts on he document, now would
be a good time to discuss them.

If someone is interested in reviewing the differences in 2538bis
compared to 2538, there is some additional resources available from:

http://josefsson.org/rfc2538bis/

Since this work is not part of the OpenPGP WG charter, it is
presumably safest to reply to me off-list.  If you feel an on-list
discussion can be tolerated, that could prove useful.

Thanks,
Simon

---

From: Florian Weimer <[email-masked]>
Date: Sun, 07 Nov 2004 14:13:25 +0100

> data packets directly, as well?

Why do you want to duplicate this information?

> be a good time to discuss them.

$ gpg --export "68FD549F" | wc -c
88127

Some OpenPGP certificates may have to be split across multiple
resource records.  Maybe DNS isn't such a great place to store them
after all. 8-/

In the URI type, it would be nice if some hashes are included.  As a
result, the protection offered by DNSSEC one day would extend to the
referenced document.

NAPTR records offer an interesting perspective for mapping domains
(and email address) to certificate references.  Such records could
look like this one:

  _openpgp.example.org IN NAPTR 10 10 "u" "PGP+D2U"
    "!^(.*)@example.org$!http://ca.example.org/lookup.cgi?user=\\1!"

(Some fields are probably completely wrong, I'm not well-versed in
NAPTR records yet.)

---

From: David Shaw <[email-masked]>
Date: Tue, 23 Nov 2004 15:56:17 -0500

>    using CNAME can be used to avoid data duplication.

One of the things that struck me when reading this draft is that while
there are several suggested ways to name keys in DNS, there is no one
canonical name as a SHOULD or MUST.  I suggest that the key
fingerprint be the canonical name, and all others be CNAMEs pointing
to the fingerprint name.

I have general concerns about the size of OpenPGP keys in DNS, but I
wonder if DNS would be a good way to distribute revocation
certificates in a low-overhead sort of way.

David

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 01 Dec 2004 03:52:01 +0100

David Shaw <[email-masked]> writes:

> One of the things that struck me when reading this draft is that
> while there are several suggested ways to name keys in DNS, there is
> no one canonical name as a SHOULD or MUST. I suggest that the key

I'm aware of this, and it is a touchy issue.  I was trying to avoid
it. Traditionally, few RR types enforce rules for the owner name.  It
may be contentious to add this.  I'll add an open issue: whether to
enforce owner name guidelines with SHOULD/MUST.

> certificates in a low-overhead sort of way.

Right.  If there were no SHOULD/MUST on the owner name rules, perhaps
storing revocation certificates under "rev-0xB565716F" would work,
which might avoid storing both the key itself and the revocation
information under the same name.  If they are stored under the same,
the response would include both, and be large, so the advantage of
using DNS as a light-weight revocation checking infrastructure is
lessened.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 01 Dec 2004 03:45:18 +0100

> Why do you want to duplicate this information?

Are you saying any OpenPGP data in the CERT RR should be permitted?

I think RFC 2538 was unclear on this, but it seems clear that at least
it was intended to store self-signed OpenPGP keys.  Given that X.509
CRLs are supported by the same document, one could argue that OpenPGP
revocation certs should be permitted as well.  But any OpenPGP data?

The text currently says:

   Public keys can use the OpenPGP public key packet (tag 6) or public
   subkey packet (tag 14), as described in section 5.5 of [5].
   Revocation signatures can use an OpenPGP signature packet with a
   revocation signature type, i.e., signature type 0x20, 0x28 or 0x30,
   as described in section 5.2 of [5].

It was mostly meant to illustrate that OpenPGP data is sub-typed.

I don't have a preference, but I think the updated document should be
clear on exactly what kind of data may be stored in the RDATA portion.
Permitting any OpenPGP data may a simple solution.

> resource records.  Maybe DNS isn't such a great place to store them

This is certainly a problem.  The update should at least acknowledge
this.  There are some ideas on how to solve the problem in
draft-josefsson-cert-openpgp.txt, but I'm not sure it is a good idea.

> result, the protection offered by DNSSEC one day would extend to the

That seem to be a good suggestion, I'll add it.

>     "!^(.*)@example.org$!http://ca.example.org/lookup.cgi?user=\\1!"

Right, but that is out of scope for 2538bis.

Thanks,
Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Please review OpenPGP part of RFC 2538bis
Date: Wed, 01 Dec 2004 03:52:01 +0100
Lines: 42
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:clt2g/GusJg5eQXWyHNxJRwVlFo=
Sender: [email-masked]

Thanks,
Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Please review OpenPGP part of RFC 2538bis
Date: Wed, 01 Dec 2004 03:45:18 +0100
Lines: 61
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:3ALmS4zO1tfmCLlwvh0Kl/pMK9g=
Sender: [email-masked]

> Why do you want to duplicate this information?

Are you saying any OpenPGP data in the CERT RR should be permitted?

I think RFC 2538 was unclear on this, but it seems clear that at least
it was intended to store self-signed OpenPGP keys.  Given that X.509
CRLs are supported by the same document, one could argue that OpenPGP
revocation certs should be permitted as well.  But any OpenPGP data?

The text currently says:

   Public keys can use the OpenPGP public key packet (tag 6) or public
   subkey packet (tag 14), as described in section 5.5 of [5].
   Revocation signatures can use an OpenPGP signature packet with a
   revocation signature type, i.e., signature type 0x20, 0x28 or 0x30,
   as described in section 5.2 of [5].

It was mostly meant to illustrate that OpenPGP data is sub-typed.

I don't have a preference, but I think the updated document should be
clear on exactly what kind of data may be stored in the RDATA portion.
Permitting any OpenPGP data may a simple solution.

> resource records.  Maybe DNS isn't such a great place to store them

This is certainly a problem.  The update should at least acknowledge
this.  There are some ideas on how to solve the problem in
draft-josefsson-cert-openpgp.txt, but I'm not sure it is a good idea.

> result, the protection offered by DNSSEC one day would extend to the

That seem to be a good suggestion, I'll add it.

>     "!^(.*)@example.org$!http://ca.example.org/lookup.cgi?user=\\1!"

Right, but that is out of scope for 2538bis.

Thanks,
Simon

Date: Tue, 23 Nov 2004 15:56:17 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Please review OpenPGP part of RFC 2538bis
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-12.txt
Date: Tue, 23 Nov 2004 15:06:47 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, et al.
	Filename	: draft-ietf-openpgp-rfc2440bis-12.txt
	Pages		: 72
	Date		: 2004-11-23
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-12.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-12.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Please review OpenPGP part of RFC 2538bis
From: Florian Weimer <[email-masked]>
Date: Sun, 07 Nov 2004 14:13:25 +0100
Sender: [email-masked]

To: [email-masked]
Subject: Please review OpenPGP part of RFC 2538bis
From: Simon Josefsson <[email-masked]>
Date: Sat, 06 Nov 2004 19:48:31 +0100
Sender: [email-masked]

All,

      $ORIGIN example.org.

Thanks,
Simon