rfc5081 update

[Nikos Mavrogiannopoulos]

Daniel Kahn Gillmor wrote:

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


Would the following text in "Client hello" section be enough?
"Note that the CertificateTypeExtension structure is being used both by
the client and the server, although specified once in this document, a
practice common in the TLS protocol specification <xref target="RFC5246"/>."

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

formally rfc5081bis would obsolete rfc5081, but because there wasn't
interest in any working group for this document, it is an independent
submission, that documents the way we use in gnutls openpgp
certificates. More authors wouldn't affect the process since a WG has to
show interest.

The independent submission proccess is at:
http://www.rfc-editor.org/indsubs.html
The ietf standard process is at:
http://www.ietf.org/IETF-Standards-Process.html

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

I changed the sentence:
"Since those certificates might contain several subkeys
                   the subkey to be used for this session is explicitely
                   specified in the OpenPGPKeyID field, even if the
                   certificate has a single subkey."
with:
"Since those certificates might contain several subkeys
   the subkey ID to be used for this session is explicitely
       specified in the OpenPGPKeyID field. The key ID must be specified
even if the certificate has only a primary key."


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

I've changed it to:
   struct {
       opaque OpenPGPKeyID<8..255>;
       opaque OpenPGPCert<0..2^24-1>;
   } OpenPGPSubKeyCert;

   struct {
       opaque OpenPGPKeyID<8..255>;
       opaque OpenPGPCertFingerprint<20..255>;
   } OpenPGPSubKeyFingerprint;


Plus the text:
"Implementations of this protocol MUST ensure that the sizes,

of key IDs and fingerprints, in the
OpenPGPSubKeyCert and OpenPGPSubKeyFingerprint structures
comply with <xref target="RFC4880"/>. "

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

Yes but in other cases one might index openpgp keys by the primary key
ID and thus might be required to retrieve it.

I changed:
"This tag uses the OpenPGPSubKeyFingerprint structure
                   and requires the subkey ID to be specified as well."
to:
"This tag uses the OpenPGPSubKeyFingerprint structure
and requires the primary key fingerprint to be specified, as well
as the subkey ID to be used for this session."

> bother including the fingerprint of the main key?  Why not just
> include the fingerprint of the relevant sub/primary key?

This is a method for retrieving keys and shouldn't force one to index
all the subkeys of a single certificate.

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

In the terminology section it says:
"We use the term "OpenPGP certificate" to refer to
             OpenPGP keys that are enabled for authentication."

This was intended to specify that keys must have the authentication
usage flag set. I think I should also make it explicit in the document
by appending to:

"OpenPGP certificates to be transferred are placed in the
Certificate structure and tagged with the OpenPGPCertDescriptorType
"subkey_cert". Since those certificates might contain several subkeys
the subkey ID to be used for this session is explicitely
specified in the OpenPGPKeyID field.
The key ID must be specified even if the certificate has only a primary
key. The peer once receiving this type has to either use the specified
subkey or terminate the session with a fatal alert of
"unsupported_certificate"."

the:
"The subkeys to be used with this protocol SHOULD have the
authentication flag (0x20) set."


regards,
Nikos