Re: [Ace] Keeping the same key identifier for groups

[Ludwig Seitz <[e-mail]>]

On 19/08/2019 22:40, Jim Schaad wrote:
> As Ludwig pointed out during the F2F, it makes far more sense to try and
> keep an entity using the same key identifier for as long as possible.  This
> is in part to make sure that signing keys do not need to be retrieved if
> they can be easily cached.  In looking at this deeper during my
> implementation I ended up with the following question:
> 
> The way that I have set things up in my implementation it is simple to
> ensure that the same kid value is going to be used with the same CWT,
> however it might make more sense to use the signing key as the continuity
> identifier instead.  The issue that arises in this case is that there might
> be two different active CWT objects that are associated with the same
> signing key.  That is there are two CWTs but the same signing key was used
> while doing a join operation.   I already do some matching between different
> CWTs by assuming that if the bearer key in the CWT is the same then they are
> sufficiently equivalent to threat them as the same.  This lead to some
> interesting discussions in Montreal about if this meant just the "secret" or
> if it meant all of the elements provided by the AS which are used in the key
> derivation process.  (I have gone back and forth on this and currently am
> sitting on the "just the secret" side of the fence.)
> 
> Does anyone have any opinions?
> 
Could you please expand the explanation of your use case a bit?

Are you thinking of a scenario where someone would be using the 
counter-signature key from group-OSCORE as a proof-of-possession (pop) 
key in serveral CWTs?

What would these CWT authorize?

Why would an entity hold several CWTs for the same audience?


Side-note:
My stance on multiple CWTs linked to the same pop-key and for the same 
audience is that the latter one should supersede the previous ones.
Example: If you have a CWT authorizing A for audience Z and you now also 
need authorization B for audience Z, you should request a CWT for A+B 
for audience Z, that replaces your previous one.

/Ludwig




-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]