Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad <[e-mail]>]

Thinking things through, I would be more comfortable with something like the
following:

1.  Create a confirmation called 'computed key id'.  This has two basic
values:  What is the computation method?  What is the proof value?  You can
optionally have an unprotected KID value used to filter the set of keys on
the RS down to a reasonable set to enumerate (hopefully one).

2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
method as a parameter.  Given that this can be computed independently by all
entities based on a Public Key value and it will be unique then you have a
key identifier that will not have collisions independent of who issues the
CWT.

3.  For PSK and TLS:  Define a method which takes some parameters including
the key value, the CWT issuer identity and perhaps some random string and
compute a proof of possession value on the PSK.  

4.  For PSK and OSCORE: Define a similar method the question would be what
the key value is to be used but that can be defined as part of OSCORE

When using the keys for TLS

For RPK the key is carried in the handshake and the server/client can
generate the computed key id and compare it to what the AS distributed.  The
server can identify which CWTs are applicable by either comparison of the
RPKs or the computed key id.  This means you have a high probability that
you will not make a mistake and match to the wrong key.

For PSK the identifier is carried in the handshake which is used to look up
a key value and the handshake is performed.  By matching computed key ids
with the secret value one can ensure to a high probably that only CWTs that
reference the same secret are going to be used for permissions even if they
come from different AS entities.

For OSCORE it is similar, the identifier is used to look up a key value and
by decrypting the CWT the key value is proofed.  You then match computed key
ids in the same manner.

If you really want to have something that is not cryptographically computed
and point to something else, then it makes more sense to me to reference a
CWT issued by the same entity and say "use the same conformation method as
this CWT does".

jim

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Saturday, June 23, 2018 11:30 PM
> To: Mike Jones <[e-mail]>
> Cc: Hannes Tschofenig <[e-mail]>; Jim Schaad
> <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote:
> > See my note just now proposing this text to Jim:
> >
> > "Likewise, if PoP keys are used for multiple different kinds of CWTs in
an
> application and the PoP keys are identified by Key IDs, care must be taken
to
> keep the keys for the different kinds of CWTs segregated so that an
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for the
> wrong kind of CWT."
> >
> > As long as the PoP keys for different contexts are kept segregated, Key
ID
> collisions or reuse cause no problems.
> 
> If we trust everyone to implement things properly.  We should probably
only
> take that risk if we get some other benefit from it, though.  Jim
mentioned
> (off-list?) a scenario involving giving the same client additional
privileges, and
> of course we can gain some simplicity savings if we don't need to enforce
> global key-id uniqueness (for appropriate values of "global").  So this
may
> well be the right thing to do; I just don't think it's without tradeoffs
as your
> text seems to imply.
> 
> -Ben