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? Grüße Olaf _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
