Subject: Re: RFC 2538bis

From: Simon Josefsson <[email-masked]>
Date: Mon, 03 Jan 2005 01:57:53 +0100

Dear All:

Since publishing rfc2538bis-00, I have received a number of comments,
mostly from the PKIX and OpenPGP working groups.  The suggestions have
been incorporated, or left as open issues (discussed below).

I have submitted the -01 draft to the IETF.  It can also be found at:

http://josefsson.org/rfc2538bis/draft-josefsson-rfc2538bis.txt

Thanks to rfcdiff, you may review the changes in that document
compared to RFC 2538:

http://josefsson.org/rfc2538bis/draft-josefsson-rfc2538bis-from-rfc2538xml.diff.html

A complete resource with XML, HTML, and TXT versions, and the two
input documents that motivated this work, can be found at:

http://josefsson.org/rfc2538bis/

The major addition in -01 compared to -00 are the new paragraphs in
section 3 that introduce the terms "content-based owner name" and
"purpose-based owner name".  The intention is to motivate the new
owner name guidelines.  As you might recall, for my needs, the RFC
2538 guidelines were not possible to use.  This was the motivation for
2538bis in the first place.

New since -00 is also the purpose-based owner name guideline for
X.509. However, this has been discussed earlier in:

http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt

Feedback on the new material are especially appreciated.

The document still mention three open issues.  I propose to resolve
the open issues as follows.  If there are no objections, I will
incorporate my proposals and publish -02.

If no further issues are brought up, I hope the document can be ready
for last call before the next meeting.

Issue #1: Handling of X.509 or OpenPGP data that is larger than 64kb.
This was discussed in section 4 of:

http://josefsson.org/gpgkeys_jkp/draft-josefsson-cert-openpgp.txt

However, it was pointed out that the specific proposal did not work
(because if the RDATA is 65535 there is no room for other data).  A
modified approach, that "chunk" the data appear to be feasible,
though.

To illustrate the problem, Philip Zimmermann's PGP key is over 100kb
large, and would not fit in a CERT RDATA field.

Because I am not aware of anyone except me who has discussed or
proposed a solution to this problem, it may be that it is not
considered a major issue.  Further, solving this appear to be
complicated to describe.  And the need doesn't appear to be great.

Finally, should this turn out to be a critical problem in the future,
the document could be updated again.

Proposal: Add the following text in a new section "Size limit":

   The RDATA field in DNS is restricted to 65535 octets (64kb).  This
   means that each CERT RR cannot contain more than 64kb worth of
   payload.

Issue #2:  Quoting the document:

   2.  Whether to enforce owner name guidelines with SHOULD/MUST.

       From David Shaw (on OpenPGP): "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.".

       From Sean P.  Turner (on PKIX): "Should "recommended" be
       "RECOMMENDED" in the 1st and 2nd sentences?"  referring to the
       text in section 3 that recommend appropriate owner names.

Since this issue was brought up in both PKIX and OpenPGP WGs, I
believe it should be addressed.  I'm inclined to agree with David's
proposal.

Unless someone knows of a good reason, preferably in the form of a
deployed use of the CERT RR, or an argument based on DNS traditions,
that would violate making the (using the new terminology)
purpose-based owner name rules a SHOULD, that is what I propose.

Proposal: Add "Implementations SHOULD use the purpose-based owner name
guidelines described in this document, and MAY use CNAMEs at the
content-based owner names, pointing to the purpose-based owner name.".

Issue #3: Quoting the document:

   3.  Should the document suggest use of both full fingerprints, 4/8
       byte OpenPGP key id owner names?  Perhaps only fingerprint
       version.

This is slightly related to the previous issue.  It may be argued that
the purposed-based owner name that SHOULD be used is the full OpenPGP
key fingerprint (this is what David propose), and that the others MAY
be CNAMEs.

However, I'm not sure this will work well.  Consider two full
fingerprints that have the same 4 byte key id:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567

Now, this won't work:

01234567 IN CNAME aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567
01234567 IN CNAME bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567

and although:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567 IN CNAME 01234567
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567 IN CNAME 01234567

would work, it means that querying for either of the two full
fingerprints will result in both keys under one name:

01234567 IN CERT <key for aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567>
01234567 IN CERT <key for bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567>

which is inefficient, because both the client and the server knew the
full fingerprint the client wanted.

Proposal: Mention this issue, and suggest that implementations MAY
chose to not use CNAMEs in this situation (thus violating the MAY in
issue #2), but rather serve the same key at several CERT RRs.

This happen to be what I implement.  My PGP DNS server answer queries
for full fingerprints, 4 and 8 byte key ids, and return the full CERT
RR immediately, without CNAMEs.  This has shown to be simple and
robust.

Thanks,
Simon

--
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: Ben Laurie <[email-masked]>
Date: Wed, 26 Jan 2005 13:13:24 +0000

> Feedback on the new material are especially appreciated.

2.1 Changing from "PGP cert" to "OpenPGP packet" allows things like 
encrypted messages to be stored in the DNS, which is probably not 
intended (though perhaps amusing).

3.1 (4) PGP -> OpenPGP.

3.2 The purpose-based name for a CRL is "Hostname of the issuing CA" - 
this strikes me as an error - it should be the DN of the CA certificate, 
surely?

3.3 Existing keyservers permit lookup by username only - it would be 
nice to preserve this functionality (though I'll confess I don't have a 
good suggestion for how!).

It might also be nice somewhere to mention that if the emails 
[email-masked] and [email-masked] both exist, they will transform to 
the same domain name, and so the OpenPGP packets for both emails should 
exist at that name, just for clarity.

3.4 for clarity it might help to say "Applications that receive an 
OpenPGP packet _containing encrypted or signed data_..."

6. If DNSSEC is used then the non-existence of a certificate can be 
securely asserted, but not with plain DNS. I think this should be mentioned.

> complicated to describe.  And the need doesn't appear to be great.

An easy solution would be to allow a Certificate Type Value of INDIRECT, 
where the body of RR is the (HTTP?) URL from which the full certificate 
can be retrieved.

> content-based owner names, pointing to the purpose-based owner name.".

Agreed.

> issue #2), but rather serve the same key at several CERT RRs.

Agreed.

Cheers,

Ben.

-- 
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, 26 Jan 2005 15:02:40 +0100

Hello Ben, thanks for the feedback.

The updated document has been finished, but I'm having trouble getting
the I-D editor to accept it as a WG document.

Meanwhile, the live version is available from
<http://josefsson.org/rfc2538bis/>.

If the editor ask for a new copy, I'll send them the version that has
been updated as per your suggestions, but otherwise it will end up in
the next version.

> intended (though perhaps amusing).

This was discussed in the OpenPGP WG, see:

http://thread.gmane.org/gmane.ietf.openpgp/5458

and in particular

http://article.gmane.org/gmane.ietf.openpgp/5462

The problem with not allowing any packet is that then you need to
specify specifically which packets are permitted.  I tried that
approach in -00, which read:

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

However, it is not clear to me that the list of packets above is
exhaustive.  An incorrect list would be bad.  My OpenPGP knowledge is
too limited to assert an exhaustive list, so I am leaning toward the
text that was derived from Florian's proposal in the OpenPGP WG:

   The PGP type indicates an OpenPGP packet as described in [5] and its
   extensions and successors.  Two uses are to transfer public key
   material and revocation signatures.  The data is binary, and MUST NOT
   be encoded into an ASCII armor.  An implementation SHOULD process
   transferable public keys as described in section 10.1 of [5], but it
   MAY handle additional OpenPGP packets.

It does not seem to me that an CERT RRs with an encrypted packet
should be considered a syntax error, so this solution seem sufficient
to get interoperability.

I'm not completely sure, but this issue doesn't seem that different
from various X.509 variations (think degenerative v1 certificates, or
weird extensions), which supposedly are also permitted even though it
is practically useless.

> 3.1 (4) PGP -> OpenPGP.

Fixed, thanks.

> this strikes me as an error - it should be the DN of the CA certificate, 

Translated into a domain name how?

I admit the purpose-based X.50 owner name rules may be a bit sketchy.

I have only experience with them for S/MIME and TLS certificates.

> good suggestion for how!).

That would be the content-based owner name guideline, no?

RFC 2538 said you should put the OpenPGP key with user id
[email-masked] at the domain name jas.extundo.com.

> exist at that name, just for clarity.

No, I think [email-masked] should be put at a\.b.example.com and
[email-masked] at a.b.example.com.  As far as I know, this is how
dots inside SOA RNAME has always been handled, and is what RFC 2538
refer to as the "standard translation".

See RFC 1035 section 5.3 for an example.

> OpenPGP packet _containing encrypted or signed data_..."

Done.

> securely asserted, but not with plain DNS. I think this should be mentioned.

I added:

  <t>If <xref target="I-D.ietf-dnsext-dnssec-intro">DNSSEC</xref> is
    used then the non-existence of a CERT RR, and consequently
    certificates or revocation lists, can be securely asserted.
    Without DNSSEC, this is not possible.</t>

> where the body of RR is the (HTTP?) URL from which the full certificate 

That seem to be a good idea to me.  It could be described and
registered in a separate document, though.

On the other hand, it may be so simple to do that it is worth adding.
Doing so would solve this currently unaddressed problem in the
document, a problem which do lead to some practical difficulties.

If you want to propose a section on it, and nobody objects, I think it
could be added.

Whether we can publish 2538bis as DRAFT or recycle at PROPOSED may be
a factor here.  I don't know what people's thoughts is on this.  My
feelings are that recycling at PROPOSED is fine, since 2538 has not
been widely deployed.

Thanks,
Simon

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Jan 2005 14:42:48 +0000

> should be considered a syntax error, so this solution seem sufficient

OK.

> weird extensions), which supposedly are also permitted even though it

Of course, you can put extensions into X.509 to do anything, its true.

> Translated into a domain name how?

Well, one way would be to hash it. The hostname is unworkable, though - 
most CA certs don't include a hostname at all, and even if they did, it 
is likely to be ambiguous (which is acceptable, but inefficient).

Hmm. An issue is that then there's no difference between the cert and 
the CRL's names. Of course, a compliant cert says where the CRL is 
anyway, so perhaps we shouldn't even be including CRLs?

> I have only experience with them for S/MIME and TLS certificates.

Then look at some TLS CA certs :-)

> [email-masked] at the domain name jas.extundo.com.

I meant their "real name" (e.g. "Simon Josefsson") not their email.

> refer to as the "standard translation".

Ah, excellent, withdrawn.

Agreed.

> document, a problem which do lead to some practical difficulties.

It would prevent the publication of the public PGP keyring, which seems 
a shame!

BTW, CRLs are often well over 64 kB, too.

> If you want to propose a section on it, and nobody objects, I think it

You'll need to change "certificate or CRL" in 2 to "certificate, CRL or 
URL", add in 2.1

   4    IPKIX    The URL of an X.509 data object
   5    ISPKI    The URL of an SPKI certificate
   6    IPGP     The URL of an OpenPGP packet

Then text:

The IPKIX, ISPKI and IPGP types indicate a URL which will serve the 
content that would have been in the "certificate, CRL or URL" field of 
the corresponding (PKIX, SPKI or PGP) packet types. These packet types 
MUST be used when the content is too large to fit in the CERT RR, and 
MAY be used at the implementations discretion. They SHOULD NOT be used 
where the entire UDP packet would have fit in 512 bytes.

Not religious about that last sentence, but it seems like a good idea.

> feelings are that recycling at PROPOSED is fine, since 2538 has not

I guess we're not in a huge rush.

Cheers,

Ben.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Jan 2005 17:38:39 +0100

Ben Laurie <[email-masked]> writes:

>>> this strikes me as an error - it should be the DN of the CA
>>> certificate, surely?

I have removed it.

If anyone distribute CRLs through CERT RRs and care about this issue,
let me know.

> Then look at some TLS CA certs :-)

I meant S/MIME user certificates and TLS server certificates.

I'm not sure there is a good use case for ever storing CA certificates
in the DNS.  (Except for self-signed user/server certificates.)
Perhaps for OCSP or CMP?  I dunno.

All this seem to be speculation, so it doesn't belong in the document
yet, I think.

>>> 3.3 Existing keyservers permit lookup by username only - it would
>>> be nice to preserve this functionality (though I'll confess I don't
>>> have a good suggestion for how!).

Oh, I see.

I don't see any way to achieve this, the DNS do not handle
directory-like searches.  I don't see keyservers going away, though,
so this functionality isn't critical.

I agree it would be a nice addition, if there were a proposal on how
to do it, though.

>>> An easy solution would be to allow a Certificate Type Value of
>>> INDIRECT, where the body of RR is the (HTTP?) URL from which the
>>> full certificate can be retrieved.

Indeed.

>   6    IPGP     The URL of an OpenPGP packet

One objection would be that it doesn't scale well.  Every certificate
format would now need two sub-types.  One direct, and one indirect.

However, I don't anticipate the IETF standardizing hundreds of
certificate-like formats in the short term, though, so it may be
acceptable.

Btw, is the size issue relevant for SPKI certificates?  I have never
seen large (>>20kb) SPKI blobs.  SPKI is EXPERIMENTAL too, so I don't
think we cannot normatively reference it.  It may be better to keep it
reserved for when SPKI become a PROPOSED standard.

> Not religious about that last sentence, but it seems like a good idea.

Some discussion about the owner names for these types is probably
needed as well.

What do people think about this indirect proposal?  It is similar in
style as the existing "private URI" mechanism, but more formal.

Unless anyone object, I'll add this, as it resolve a known practical
problem with CERT RR.

Thanks.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Jan 2005 17:24:38 +0000

> If anyone distribute CRLs through CERT RRs and care about this issue,

Seems fair to me.

> in the DNS.  (Except for self-signed user/server certificates.)

That alone sounds like a good case - particularly if served over DNSSEC!

> All this seem to be speculation, so it doesn't belong in the document

I'm not sure what you want to remove now?

> I agree it would be a nice addition, if there were a proposal on how

I'll think about it.

> format would now need two sub-types.  One direct, and one indirect.

Its a bit otherwise, which has the same effect :-)

> reserved for when SPKI become a PROPOSED standard.

I don't know enough about SPKI to answer this.

> Some discussion about the owner names for these types is probably

It would be exactly the same as for the corresponding direct type.

> style as the existing "private URI" mechanism, but more formal.

The private URI allows you to specify a packet format with a URI, so it 
isn't really the same thing.

Cheers,

Ben.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Jan 2005 18:43:39 +0100

> That alone sounds like a good case - particularly if served over DNSSEC!

Doing that would still be allowed, through the S/MIME and TLS owner
name guideline.

> I'm not sure what you want to remove now?

I meant that _adding_ a purpose based owner name recommendation for CA
certificates is not baked enough to be put into the document.

>>> You'll need to change "certificate or CRL" in 2 to "certificate,
>>> CRL or URL", add in 2.1
>>>

Yes.  I think your approach is good.

>>> content that would have been in the "certificate, CRL or URL" field
>>> of the corresponding (PKIX, SPKI or PGP) packet types. These packet
>>> types MUST be used when the content is too large to fit in the CERT
>>> RR, and MAY be used at the implementations discretion. They SHOULD
>>> NOT be used where the entire UDP packet would have fit in 512
>>> bytes.
>>>

I'll try to add something.

> isn't really the same thing.

You could have the packet format be an URI.  I.e., the RDATA would be:

http://josefsson.org/my-cert-rr-uri-proposal.txt\0http://josefsson.org/cert.txt

But your proposal is more practical.

Thanks.

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 27 Jan 2005 09:44:56 +0000

> I agree it would be a nice addition, if there were a proposal on how

No. That's a distraction.

It's not just that "the DNS do not handle directory-like searches".

The proper place in the DNS hierarchy to advertise a real name is 
undefined.
Any definition would have to include a strategy for avoiding collisions 
with
other instances of any particular name.  Whatever the necessary 
scattering
scheme might be, it would make retrieval "interesting", to say the 
least!

Still, it's that time of the year, and nine weeks from tomorrow is an
auspicious date. 8-)

Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Ben Laurie <[email-masked]>
Date: Thu, 27 Jan 2005 10:10:19 +0000

Niall O'Reilly wrote:
>> directory-like searches.  I don't see keyservers going away,
>> though, so this functionality isn't critical.
>> 
>> I agree it would be a nice addition, if there were a proposal on
>> how to do it, though.
> 
> 

I was thinking along the lines of having a root name under which real 
names were stored. Of course, there could be more than one, just as 
there are multiple PGP keyservers.

> Any definition would have to include a strategy for
> avoiding collisions with other instances of any particular name.
> Whatever the necessary scattering scheme might be, it would make
> retrieval "interesting", to say the least!

Collisions aren't an issue, you just have multiple RRs at the name.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Jan 2005 11:57:23 +0100

> The proper place in the DNS hierarchy to advertise a real name is 

I don't see why it is impossible to define a way, without studying the
problem further...

I agree with you that this is a distraction, and probably beyond the
scope of 2538, though.

But given DNSSEC NSEC walking, you can get a pretty good telephone
book system.  Type 'S' and the NSEC chain allow a client to show all
entries close to S.

> other instances of any particular name.

Right.  The strategy might be as simple as not trying to avoid
collisions, and returning multiple data items, one for each match.

Regards,
Simon

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Jan 2005 11:59:00 -0500

At 9:44 +0000 1/27/05, Niall O'Reilly wrote:
>The proper place in the DNS hierarchy to advertise a real name is undefined.

(I'm not sure if you infer that there should be one...but here's the 
knee-jerk rant:)

There is no proper place in the DNS hierarchy to "advertise" anything.

It's like walking through a library (the old kind, with bookcases, 
shelves, and books) blindfolded and with one of them tracking 
numbers.  You travel to where the book identified by the tracking 
number is and reach for it.

It's either "there" or not at all there.  There is no fuzziness.

>Any definition would have to include a strategy for avoiding collisions with
>other instances of any particular name.  Whatever the necessary scattering
>scheme might be, it would make retrieval "interesting", to say the least!

That's an application problem, not a DNS problem beyond the desire to 
keep the books in the library easy to lift off the shelves by even 
the "weakest" customers of the library.

>Still, it's that time of the year, and nine weeks from tomorrow is an

Maybe I ought to submit an ID on the DNS SEARCH RR for then.

;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 27 Jan 2005 17:42:24 +0000

<agreement class="violent">

On 27 Jan 2005, at 16:59, Edward Lewis wrote:

> shelves, and books) blindfolded and with one of them tracking numbers. 
>  You travel to where the book identified by the tracking number is and 
> reach for it.
>

Absolutely.

Keeping your metaphor, what I meant by "advertise" was the process of 
selecting
the tracking number in order to place the book on the right shelf -- a 
combination
of what my colleagues over in the library building call "cataloguing" 
and "shelving".
If I get that part right, someone else who understands the cataloguing 
system can
actually find ("retrieve") the book.  In the sense that this is 
arbitrary, there
is indeed no "proper" place.  In the sense that the scheme is 
documented and well
understood by the parties involved, there _is_ a "proper" place.

More concretely, my telephone number has one very well defined "proper" 
place
in the DNS hierarchy where I "advertise" its "properties" for 
"retrieval"
in a useful way by others.  I could choose some other place to enter 
the RRs with
the same RHS data, but doing so would frustrate the "standard" 
retrieval process.

Enough for now ...

</agreement>

Best regards,

Niall O'Reilly

1.7.0.2.6.1.7.1.3.5.3.e164.arpa
PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Jan 2005 11:04:26 +0700

Date:        Thu, 27 Jan 2005 17:42:24 +0000
    From:        "Niall O'Reilly" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Keeping your metaphor, what I meant by "advertise" was the process of 
  | selecting the tracking number in order to place the book on the right
  | shelf

I think Ed's point was that this neither is, ever has been, or ever should
be, a function of the DNS.

  | combination of what my colleagues over in the library building call
  | "cataloguing" and "shelving".

The former is outside the DNS, the latter inside.

  | More concretely, my telephone number has one very well defined "proper" 
  | place in the DNS hierarchy

That's fine.

  | where I "advertise" its "properties" for "retrieval"
  | in a useful way by others.

Yes, you advertise, or some other thing does, the DNS does not.

With the DNS, you must know, from some other means, the precise key,
catalogue number, (domain name) before you start, from some other
mechanism.   That may be from digging it out of a URL, using the
domain name part of a From field body in an e-mail, following some
precise rule set out to convert some other data (IP address, phone
number) or whatever.

When you do the query, you get a relatively small answer that is
intended to tell you exactly what you wanted to know (there should
be no aspect of guessing, searching, or other speculation as to
whether the answer returned is really intended for you or not, if
you asked, and an answer was returned, that *is* your answer).

kre