Subject: OpenPGP data in the CERT RR

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Aug 2002 14:57:49 +0200

I have tried to summarize the needs OpenPGP data in DNS have, abstract
and URL to draft below.  Similar discussion also applies to S/MIME,
but I'm publishing the OpenPGP document now as it is developed as free
software and has more to gain from public debate.

It would be nice if this WG could decide which approach for
application keying material in DNS they would rather see, otherwise
every application is likely to design this separately.  The draft
below is one attempt to solve this separately, there is a draft for
IPSEC with another solution, and drafts for other application seems to
be in preparations.  Perhaps they can be reviewed and lead to a WG
recommendation. I've tried to raise this discussion a few times, but I
see little consensus or (in the words of Mr. Vixie) leadership in
solving this problem in a way that DNSEXT would prefer.  How do you
want it to be solved?

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

Abstract

   This draft describes the decisions made in one pair of applications
   [4][5] that respectively serves and retrieve OpenPGP [3] Certificates
   and Revocation Signatures using the CERT Resources Record [2].  The
   intent is to provide a discussion on the kind of general updates
   needed to the CERT specification, and some suggested specific updates
   for the OpenPGP sub-type.  It is offered in the hope that this
   specification, together with similar efforts for other applications,
   can be reviewed when designing a generic solution or guidelines for
   storing application keying material in the Domain Name System (DNS),
   should it ever happen.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: John Schnizlein <[email-masked]>
Date: Tue, 06 Aug 2002 09:24:44 -0400

>http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt

Would you please explain how the recommendation below (from the above URL)
would accommodate "friendly e-mail addresses" of the form
[email-masked]?

My concern is that replacing the '@' with '.' in order to use a label format
would create a parsing problem for FirstName.LastName.host.example. There
could be mailbox for FirstName on a host with the name LastName.host.example.

      ... However, it is recommended by PGP that such names include
      the RFC 822 email address of the party, as in "Leslie Example
      <[email-masked]>".  If such a format is used, the CERT should be
      under the standard translation of the email address into a domain
      name, which would be leslie.host.example in this case.  If no RFC 822
      name can be extracted from the string name no specific domain name is
      recommended.

John

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Aug 2002 20:56:22 +0700

Date:        Tue, 06 Aug 2002 09:24:44 -0400
    From:        John Schnizlein <[email-masked]>
    Message-ID:  <[email-masked]>

  | Would you please explain how the recommendation below (from the above URL)
  | would accommodate "friendly e-mail addresses" of the form
  | [email-masked]?

The same as is done in the SOA.rname field, one would presume.

That is, as FirstName\.LastName.host.example.

kre

ps: this message should not be taking as expressing an opinion on the
draft in question.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 10:03:06 -0400

I've not read the draft, but seen this issue come up before (e.g., 
the MNAME in the SOA).  FirstName\.LastName.host.example -> 
[email-masked].

See the note at the bottom of page 36 of RFC 1035.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 10:15:49 -0400

At 2:57 PM +0200 8/6/02, Simon Josefsson wrote:
>every application is likely to design this separately.

I think it would be preferable for applications to design solutions 
to their problems, at least at first.  If enough applications have 
designed "experimental" solutions, perhaps then we (DNSers) can 
extract a systematic solution.  Without proper input from the 
applications, expecting DNSers to design a better approach is 
unrealistic.

>solving this problem in a way that DNSEXT would prefer.  How do you

I understand your rationale for wanting the DNS community to solve 
this problem to stave off bad solutions from the applications.  But I 
think this is a siren's call.  I doubt that a good-for-DNS solution 
designed by the DNS community will also be 
good-for-(all-)applications, just as much as you doubt that a 
good-for-(each-)application solution will also be good-for-DNS.  I 
prefer the former though for a number of previously detailed reasons.

I really do want to see documents come from the applications that are 
interested in distributing keying material via DNS.  This is 
happening, there's a proto-draft for the SSH application in 
preparation.  I was disappointed that there was no IPsec OE input to 
the SIKED BoF, even though there was a draft available then.  I have 
the OpenPGP draft printed on my desk for reading next.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 13:15:09 -0400

>http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt

Issue #1 -> going from a digital signature to finding a copy of a 
certificate needed to verify the signature.  Sigh, always an issue.

This is a problem I've had experience with in the X.509 realm.  In my 
lab-baked solution, I just included a domain name with the signature 
in the data structures I passed.  I can understand how this might be 
different when trying to weld this into existing applications, like 
email.

Defining a convention for determining a domain name from a signature 
structure is one thing being done in this draft.  Not being a PGP 
expert, I can't comment or really add to the text.  One concern about 
section 2.1 is to make sure that the added bytes don't scrunch up the 
name (a concern I read in Eric Hall's expired draft on DNS data 
considerations).  A concern in section 2.2 is that relying on a CNAME 
at one name to point to another limits what can be stored at the 
owner of the CNAME.  Hopefully no other application wants to have 
data at such a name.  (These are examples of why specifying naming 
conventions can be tricky.)

The rest of the issues I've broken down section-by-section:

Section 3 is a perfect example of why applications need to do this 
work and not DNS.  (See how "we"[0] screwed up the first time?  You 
want to ask us to do this again?)  The same issue happened with SSH 
and is what prompted APPKEY.  For SSH the KEY RR was insufficient 
because the KEY RR couldn't convey the SSH version information needed 
to decipher the key.  Apparently, "PGP" isn't specific enough for the 
CERT RR.  (Maybe just more algorithm types are needed.)

Section 4 is an unforeseen problem for DNS - data too big for an RR, 
and perhaps even an RR set.  I don't know if you want to suffix names 
though, it separates data, but then again if you are worried about 
message size you want it separated.  I would argue that at this 
point, just use SRV records and make queries into a system more 
suited to large data elements.

Section 5 twists the key id field, and I don't know that you want to 
go there.  This makes the interpretation of that field (which is 
supposed to hold the key id of a KEY RR held at the same name, a 
useless appendage pending restrict-KEY) dependent on the algorithm 
field, unless we redefine that field altogether, given restrict key.

Section 6 talks about revocation, and I'm not sure I know enough PGP 
to know about this.  In X.509, I was able to store both DER-encoded 
certificates and revocation lists in the PKIX algorithm type.

One thing that helped X509 certificates in DNS.  Once I managed to 
locate the initial certificate, it had the domain names of all others 
I needed - the "AltName" of the issuer and also of the revocation 
list.  So once I entered DNS, I could bounce through the system 
easily and without neededing a name conversion convention.  I was 
even able to specify multiple domains as AltNames too.

[0] No offense intended to the editors, they were working at the 
beck-and-call of the WG.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Aug 2002 22:19:42 +0200

> different when trying to weld this into existing applications, like

OpenPGP signatures contains the Key ID of the signer, so assuming the
recipient has configured her client to look into
e.g. dnskeys.josefsson.org, this isn't a problem.

When OpenPGP is used in e-mail the sender's email address ("From:")
can be used as a hint to find the OpenPGP certificate if the recipient
simply enable DNS-based key servers, no need to specify a particular
zone to look into.

> expert, I can't comment or really add to the text.

Actually, this is under discussion, and the text in the draft will be
modified and enhanced with a rationale for the owner name
recommendation.

> One concern about section 2.1 is to make sure that the added bytes
> don't scrunch up the name (a concern I read in Eric Hall's expired
> draft on DNS data considerations).  A concern in section 2.2 is that
> relying on a CNAME at one name to point to another limits what can
> be stored at the owner of the CNAME.  Hopefully no other application
> wants to have data at such a name.  (These are examples of why
> specifying naming conventions can be tricky.)

KeyId based owner names will be used in "special" zones.  The zone
name is either configured by the recipient, or specified in the
OpenPGP preferred key server sub-packet.  So I don't expect this to be
a problem.  It would for a generic solution though.

> CERT RR.  (Maybe just more algorithm types are needed.)

The "problem" here, as I perceive it, is that the CERT specification
tried to be specific about RDATA but failed.  If it simply defined the
framework, it could leave the description of individual sub-types to
other documents.  Defining the framework is what I'd like this WG to
do.  This also splits the design of the DNS part to DNS WGs and design
of application-specific data parts to other people.

> message size you want it separated.

How would it be solved otherwise?

> I would argue that at this point, just use SRV records and make
> queries into a system more suited to large data elements.

This may lead to security problems.  If I store the data in DNS, I can
use DNSSEC or TSIG to protect the data, if I use SRV I can only
protect the pointer to the server, but the connection to that server
is not protected.

> field, unless we redefine that field altogether, given restrict key.

The Key Id field of CERT is computed on the key inside the
certificate.  It has nothing to do with the KEY RR, except the
algorithm numbers are shared.  I don't see how this "twists" the
field, from how I read the definition in RFC 2538 it looks like I'm
using it for exactly what it was intended for -- optimizing cert
selection when there are several keys/certs.

> certificates and revocation lists in the PKIX algorithm type.

Problem is that revocation data is small, so I want to separate it
from certificate data so packets aren't overflowed.  Sub-typing can't
do that though, but it was suggested to use different owner names to
solve that.

> list.  So once I entered DNS, I could bounce through the system easily
> and without neededing a name conversion convention.  I was even able
> to specify multiple domains as AltNames too.

OpenPGP has something similar, although it is not always used.  Just
as X.509, that is.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Aug 2002 22:34:11 +0200

Edward Lewis <[email-masked]> writes:

> I think it would be preferable for applications to design solutions to
> their problems, at least at first.  If enough applications have

Yes.  That's why I wrote the draft.  I used to believe that this
problem was easy enough so that a framework could be developed by the
DNS community for application developers, but I now realized this
isn't happening.  So I'll solve the problems as an application writer
and document it and leave it at that.