[Ace] Text for KID in POP

[Jim Schaad <[e-mail]>]

Add the following text to section 3.4.

WARNING: The use of a Key ID in a POP CWT needs to be carefully circumcised.
Where the Key ID is not a cryptographic value derived from the key or where
all of the parties involved are not validating the cryptographic derivation,
it is possible to get into situations where the same Key ID is being used
for multiple keys.  The implication of this, is that an RS may have multiple
keys registered with it that have the same Key ID and thus it does not know
which key the new CWT is to be associated with

In the world of constrained IoT devices, there is frequently a restriction
on the size that a key id can be either because of table constraints or a
desire to keep message sizes small.  These restrictions are going to
protocol dependent.  For example, DTLS can use a key id of any size.
However, if the key is being used with COSE encrypted message then the
length of the key needs to be minimized and may have a limit as small as one
byte.  The value of a key id is not always the same for both parties.  When
sending a COSE encrypted message with a shared key, the key id may be
different on both sides of the conversation with the appropriate one being
included in the message based on the recipient of the message.

For symmetric keys, the key ID is normally going to be generated by the CWT
issuer.  This means that enforcing a rule that key ID values only match if
CWTs have the same issuer works for matching key ids between CWTs.  In this
case the issuer can ensure that there are no collisions between currently
active symmetric keys for all CWTs that it has issued.  This allows for an
RS to use the pair of issuer and key id for matching with existing keys.

For asymmetric keys, the key ID value is normally going to be generated by
the client and thus the possibility of collisions is going to greatly
increase.  It would be normal for all clients to start by assigning a key id
of 0 given that key ids are frequently only needed to be unique and
meaningful to the client.  This problem can be addressed in a couple of
different ways depending on how the key id value is going to be used.  

* The issuer can assign a new unique key id the first time it sees the key,
depending on the protocol being used the new value may then need to be
transported to the presenter by the protocol used to issue CWTs.  In this
case the rule of requiring that the issuer, key id pair be used for matching
works.

*  The issuer can use a different confirmation method if a collision is
unavoidable.

* Clients may decide not to use a CWT based on a created key identifier if
it does not fit the clients requirements.

* If an issuer is going to issue confirmations of Key ID and is not going to
guarantee that serial number uniqueness is going to be preserved, the
relying party needs to have that information configured into it so that
appropriate action is going to be taken.


Jim