Subject: Proposed RFC 2538bis AUTH48 problem resolution

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Mar 2006 23:14:48 +0100

Dear WG:

RFC 4398 (2538bis) has been in the AUTH48 state with the RFC Editor
for some time now, pending a problem the GnuPG developers found when
implement support for storing PGP data in CERT records.  This e-mail
describe the problem and propose how to solve it, so we can get the
document out.

The problem is that it is impossible to strongly identify the intended
OpenPGP key based on the URL in the IPGP type from any DNSSEC trust,
i.e., you don't know that what you download from the URL contains the
DNSSEC-trusted OpenPGP key.

The solution to this is add a field to the IPGP type that contain the
OpenPGP key fingerprint.  This is David Shaw's proposal.

What remains is to deal with the other indirect I* types.  The problem
is similar to all of them, you may need a hash of the URL data to
bridge DNSSEC trust further.  We believe nobody care about SPKI
strongly enough to care about ISPKI, so we wish to postpone the
definition of both SPKI and ISPKI until later.  For IPKIX and IACPKIX,
the problem isn't as applicable because X.509 certs are
self-authentication and in particular RFC 4387 describe URL access
that can embed hashes of the certificate.  We propose to keep the
IPKIX and IACPKIX types, but note that if someone need a hash inside
those CERT sub-types, such new sub-types can be specified in the
future.

Here are the proposed changes that will be sent to the RFC editor
unless someone has a better suggestion.

Please, please, review RFC 4398:

ftp://ftp.rfc-editor.org/in-notes/authors/rfc4398.txt

with the patch below for consistency.

Thanks,
Simon

Section 2.1, OLD:

             6  IPGP      The URL of an OpenPGP packet

NEW:

             6  IPGP      The fingerprint and URL of an OpenPGP packet

OLD:

   The SPKI type is reserved to indicate the SPKI certificate format
   [15], for use when the SPKI documents are moved from experimental
   status.

NEW:

   The SPKI and ISPKI type is reserved to indicate the SPKI
   certificate format [15], for use when the SPKI documents are moved
   from experimental status.  The format for these two CERT RR types
   will need to be specified later.

OLD:

   The IPKIX, ISPKI, IPGP, and IACPKIX types indicate a URL that will
   serve the content that would have been in the "certificate, CRL, or
   URL" field of the corresponding types; PKIX, SPKI, PGP, or ACPKIX
   respectively.  The IPKIX, ISPKI, IPGP, and IACPKIX types are known
   as "indirect".

NEW:

   The IPKIX and IACPKIX types indicate a URL that will serve the
   content that would have been in the "certificate, CRL, or URL"
   field of the corresponding types; PKIX or ACPKIX respectively.

   The IPGP type contains both an OpenPGP fingerprint for the key in
   question, as well as a URL.  The certificate portion of the IPGP
   CERT RR is defined as a one-octet fingerprint length, followed by
   the OpenPGP fingerprint, followed by the URL.  The OpenPGP
   fingerprint is calculated as defined in RFC-2440 [5].  A
   zero-length fingerprint or a zero-length URL are legal, and
   indicate URL-only IPGP data or fingerprint-only IPGP data
   respectively.  A zero-length fingerprint and a zero-length URL is
   meaningless and invalid.

   The IPKIX, ISPKI, IPGP and IACPKIX types are known as "indirect".

Section 8, OLD:

             6   IPGP     The URL of an OpenPGP packet      RFC 4398

NEW:

             6   IPGP     The fingerprint and URL           RFC 4398
                          of an OpenPGP packet

--
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/>