rfc5081 update

[Daniel Kahn Gillmor]

On Sat 2008-11-15 11:54:30 -0500, Nikos Mavrogiannopoulos wrote:

> Daniel Kahn Gillmor wrote:
>
>>  * 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.

OK, this makes sense.

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

I suspect that i'm actually part of the target group of this paper,
and i was confused by it, fwiw.  The top of page 37 of RFC 5246 [0]
actually takes pains to explain the difference between client and
server use of the handshake messages:

   Note one exception to the ordering: the Certificate message is used
   twice in the handshake (from server to client, then from client to
   server), but described only in its first position.

Perhaps a similar clarification would be useful in 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).

OK, that's a shame.  Isn't 5081bis an RFC that updates 5081?  Or are
you saying that this would need to be handled in an additional
subsequent RFC?  Would a second author on the RFC raise it out of
"individual submission" status enough to consider allocation of a new
registry?  Sorry i don't know more about the RFC process.  Pointers to
relevant documentation would be happily accepted.

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

Yes, making it explicit in the RFC would be good.

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

In that case, shouldn't it actually be foo<8..> or something like
that?  We know that the keyids will no less then 8, but we would like
to leave it open to be larger, right?  There's no sense in capping the
size at 8 max, or allowing values lower than 8 that i can see.  Or am
i misunderstanding the syntax?

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

If this is the desired behavior, then yes, it should be made
significantly more explicit.  As one point of reference, GPG makes
very little distinction between keyids of a subkey and keyids of a
primary key.  While the output will always show the primary keyid in
most places, you can specify the keyid of the subkey with no
detriment.

I'm not sure that this should be the desired behavior, though.  Why
bother including the fingerprint of the main key?  Why not just
include the fingerprint of the relevant sub/primary key?  Why would
you only include the keyid of the key to actually be used, instead of
the fingerprint?  It seems to me like just supplying the fingerprint
of the specifically-relevant (primary or sub) key would be sufficient.

One other question:

Should there be any recommendation that the (primary or sub) key
should have any particular Usage flags set?  I think it would be
appropriate to suggest that keys with the Authentication Usage Flag
(0x20) SHOULD be used, since authentication is the specific use of the
keys in this context (AIUI, the Encrypted Communications Usage Flag
(0x04) is not relevant because the communications are in fact
encrypted by the negotiated cipher suite, *not* by the private keys of
either party).

Thanks very much for your work on this specification, Nikos!

Sincerely,

        --dkg

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