On Wed, Jul 01, 2020 at 10:25:27AM +0200, Olaf Bergmann wrote: > Hi Jim, > > Jim Schaad <[email protected]> writes: > > > If you are not doing a re-encoding of the token, then I believe that > > preferred serialization and deterministic serialization are going to > > generate the same answer. With the map being used then this is not > > true, and it is also true that the change in map ordering will hit > > this. > > There seems to be agreement on this, and therefore I will change the > text following Carsten's proposal (use bytes for the access_tocken and > state that preferred serialization and deterministic serialization > should be used for the CBOR serialization. > > > This is a piece of the document that I have never implemented > > because I just don't believe that this option is a reasonable thing to > > require being done so I missed the fact that the original encoded > > token is not being used. > > You haven't missed anything—the intention always was to use the original > encoded token as transferred on the wire. The issue was introduced in > this last unpublished change that should have clarified the > serialization of the data structure that is used as input for the HKDF. > > > There is a possible DOS attack by a MITM changing the encoding on the > > token since it is not protected when posted to the RS. > > Yes, this is inherent to the upload mechanism and unrelated to key > derivation. My intention is to access-protect the token endpoint in my > implementation such that only authorized clients can upload an access > token. > > > If this is going to be changed, I would say use the binary string > > encoding from the bstr of the inner most COSE wrapping layer as the > > input to minimize this. > > Now you have lost me. The innermost COSE wrapping layer would be the one > in the contents of the cnf claim, given that we do not invent claims > that also can include COSE structures?
I think the intention is the "innermost COSE structure protecting the [entire] access token", to accomodate the fact that the access token might be COSE_Mac(), COSE_Encrypt(COSE_Mac()), etc., and not necessarily a fixed number of layers of COSE protection between the access token ciphertext and the CWT claim set. -Ben _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
