rfc5081 update

[Nikos Mavrogiannopoulos]

Daniel Kahn Gillmor wrote:
> On Mon 2008-11-03 14:21:10 -0500, Nikos Mavrogiannopoulos wrote:
> 

Hello,
 Thank you for the comments. My comments inline:

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

I was thinking to make this explicit but since I'm referencing 4880 for
OpenPGP certificates I think it might be enough. In general I didn't
want to specify exactly what is allowed and not and leave this to 4880
since this is the authority for openpgp keys.

>  * 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?

Probably it would be more clear... but now it is consistent with the TLS
protocol wording (at least rfc2246 which I am familiar with). A change
in wording would confuse TLS implementors and these are the target group
of this paper.

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

The overlap is intentional. The empty_cert in 5081bis is the same as a
empty cert would be expressed in 5081. Backwards compatibility is not
really an issue since only gnutls implements this protocol and the
current implementation does not do 5081 (it conforms to 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?

The only way for this to change now is through an rfc that updates this
one. Since this is individual submission I cannot allocate IANA registry
for that. (rfc5081 was sponsored by TLS WG).

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

Indeed. However I prefer this naming because it makes explicit the fact
that subkeys can be used. (the term key id wouldn't). Should I make
explicit the fact that the main keyid could be used there?

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

Compliant with rfc5081bis but not with rfc4880 thus rejected by the
peer. However this notation has the advantage that it includes a header
with the length of foo. Thus if rfc4880 is updated an includes keyids
that are more than 8 bytes long the same structure will be able to hold
them.

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

The OpenPGPCertFingerprint should contain the fingerprint of the main
key of the certificate and OpenPGPKeyID the keyid of the subkey to be
used for authentication. Do you think that I should include this
explanation in the document?

best regards,
Nikos