Subject: Re: Proposed RFC 2538bis AUTH48 problem resolution

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Tue, 14 Mar 2006 21:57:28 -0500

Thanks Simon, for your diligent work on bringing this issue to
resolution.

Unless someone speaks up that this is unacceptable, the WG chairs
will inform the AD that making these text changes is supported by the
working group and recommend RFC2338bis be publish with these changes.
Speak up before Tuesday March 21'st.

         Olafur.

At 17:14 14/03/2006, Simon Josefsson wrote:
>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/>

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Tue, 21 Mar 2006 16:48:16 -0500

As there have been no objections to this change the chairs will
request that the RFC-editor make this change after we do more
due diligence by checked with our AD and a security AD.

         Olafur & Olaf