Quick note on the samples in cose-msg. Will look at the rest later Look in the directory spec-examples for the cose-msg examples. Some are basically duplicated in other locations. I need to do a rename of the files since I added a new appendix. That is Appendix_B_1_1.json is the example for appendix C.1.1
Jim > -----Original Message----- > From: Ace [mailto:[email protected]] On Behalf Of Michael Richardson > Sent: Monday, January 02, 2017 11:34 AM > To: ace <[email protected]> > Subject: [Ace] some comments on draft-ietf-cose-msg-24 and draft-ietf-ace- > cbor-web-token-01 > > > I am implementing some Ruby code to validate the claims shown in the appendix > A of draft-ietf-ace-cbor-web-token-01. It wasn't obvious at first, or maybe I just > don't get it, but the examples there are not, I think, signed. > We are looking at the content that would get signed. > > What I see in A.2 is a claim about a public key, but no signature: > "This is then packaged signed and encrypted using COSE." > > Are there any plans to provide a signed test vector as part of CWT? > > It also seems that perhaps CWT doesn't not need all of the modes that ietf-cose- > msg provides. Also, cose-msg has 10 further revisions since the -14 that cwt > points to... I don't know if there are any things affecting it. > > I am currently making sure that I can validate some of the vectors in > Appendix C of ietf-cose-msg. I think that the examples are from: > https://github.com/cose-wg/Examples > > I wonder if the directories could say "c-1-1" or something in them? > (or the other way around). I think that: > C.1.1. Single Signature > > is ecdsa-01.json, which has a nice > "title":"ECDSA-01: ECDSA - P-256" > > maybe that could be in the document? > > (My thanks for the LotR inspired keys!) > > I am aware that ietf-cose-msg-24 has past the WGLC... > > ietf-cose-msg-24 says on pg 11: > protected: Contains parameters about the current layer that are to > be cryptographically protected. This bucket MUST be empty if it > > and after explaining that a zero length string should be used, it > says: > "This avoids the problem of all > parties needing to be able to do a common canonical encoding." > > Isn't saying it's a zero-length string, a canonical encoding? > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works -= > IPv6 IoT consulting =- > > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
