rfc5081 update

[Daniel Kahn Gillmor]

On Mon 2008-11-03 14:21:10 -0500, Nikos Mavrogiannopoulos wrote:

> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-mavrogiannopoulos-rfc5081bis-02.txt

Sorry it's taken me a while to really read this.  I have a few
concerns.  If this is not the proper forum for airing these things,
just point me in the right direction.

 * The draft does not specify what version of OpenPGP certificates
   should be used for this.  Given that RFC 4880 explicitly deprecated
   V3 certificates, i think this draft should at least do the same.
   It would be simpler for implementation if this draft specified that
   compliant implementations MUST support V4 certificates, and MUST
   NOT use V3 certificates.

 * Section 3.1 is phrased as a comparison between client and server:

      struct {
         select(ClientOrServerExtension) {
            case client:
               CertificateType certificate_types<1..2^8-1>;
            case server:
               CertificateType certificate_type;
         }
      } CertificateTypeExtension;

    However, i think this is misleading; when the same struct is used
    during the Client Certificate Request, the server offers some
    number of CertificateType possibilities, and the client responds
    with the CertificateType of its choosing.  If i'm reading this
    right, the naming is actually backwards when the struct is used in
    section 3.5.  Maybe it would be better to refer to these struct
    elements as request/response instead of client/server?

 * It looks like the values for OpenPGPCertDescriptorType are
   overlapped: in particular, 1 is bound to "cert" in 5081, but bound
   to "empty_cert" in 5081bis.  This seems like it could cause
   problems if one party implements 5081 and the other implements
   5081bis.

 * There is no IANA registry requested for OpenPGPCertDescriptorType,
   and none is allocated in 5081 either.  Is that OK?  Could this enum
   ever change?  Who will manage addition of new values there are
   changes needed?

 * I'm concerned that the useful values for OpenPGPCertDescriptorType
   (subkey_cert and subkey_cert_fingerprint) all refer to subkeys.
   It's certainly possible to set the Authentication (0x20) Usage flag
   [0] on the primary key, or to have a primary key with no subkeys.
   While i think the obvious answer is that the keyid can refer to
   *either* the primary key or the subkey (but to a specific key, not
   to the entire aggregated certificate), it seems a little odd to
   explicitly call it the subkey id.

 * Why are OpenPGPKeyID elements written foo<1..8>.  Shouldn't we be
   requiring the full 8 bytes of keyid?  The syntax seems to imply to
   me that i could offer a 1-byte KeyID and still be compliant.

 * Why does OpenPGPSubKeyFingerprint contain both OpenPGPKeyID and
   OpenPGPCertFingerprint?  For V4 keys, the KeyID is just the
   low-order 64 bits of the fingerprint [1].  If we only allow
   V4-or-later keys in this spec, we could remove that struct element.

Hope these questions and ideas are useful.  Please let me know if i'm
not making sense.  I look forward to your feedback!

     --dkg

[0] http://tools.ietf.org/html/rfc4880#section-5.2.3.21
[1] http://tools.ietf.org/html/rfc4880#section-12.2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20081112/df8467fa/attachment.pgp>