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 namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>