Should be circumscribed not circumcised although the first does echo my personal feelings.
Jim > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Jim Schaad > Sent: Wednesday, July 18, 2018 6:13 PM > To: ace@ietf.org > Subject: [Ace] Text for KID in POP > > 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 > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
