On Sun, Nov 17, 2019 at 6:45 AM Kathleen Moriarty <[email protected]<mailto:[email protected]>> wrote: Hi Dave, On Sun, Nov 17, 2019 at 3:02 AM Dave Waltermire <[email protected]<mailto:[email protected]>> wrote: Kathleen, Thank you for the review. I have addressed your comments in the latest draft. Some comments on your comments are inline below. From: sacm <[email protected]<mailto:[email protected]>> on behalf of Kathleen Moriarty <[email protected]<mailto:[email protected]>> Date: Fri, October 25, 2019 11:57 PM +0800 To: "<[email protected]<mailto:[email protected]>>" <[email protected]<mailto:[email protected]>> Subject: [sacm] CoSWID review Section 2.6: A Thumbprint is specified in this section, should this be referenced for clarity on hashes with COSE for object identification: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C75ba45cd96ab47c1496808d76c23fd62%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637096774138383674&sdata=7FGlZBW3KNZeR7ur3baxZKvGm5m8jYR%2BdQnng6L1%2Bmc%3D&reserved=0> Would it be better to tie to the COSE set of supported algorithms (they likely match, but I didn't verify)? The IANA COSE Algorithms registry contains other types of algorithms beyond hash algorithms. To use this registry, we would need to list the hash-specific algorithms, which is less ideal. Its a shame this registry isn't broken out by algorithm type, which would make this decision easy. With the IANA "Named Information Hash Algorithm Registry", we get only hash algorithms, which is what we are looking for. Can you live with use of the IANA "Named Information Hash Algorithm Registry"? COSE is open as is their main draft. This is a problem that can likely be solved this week... Talk to Jim. Let me and the list know what's possible. Section 5: It might be helpful to list what is being requested at the start of the IANA section X registries are established with this request with initial entries for X registries. Values for Z existing registries are requested. Done. Thanks. 5.1: s/This document uses integer/This registry uses integer/ Fixed. Section 5.2.5: s/This document defines a new a new a/This document establishes a/ Fixed a bunch of cases that matched this pattern. Thanks for catching this. Just trying to head off issues at the later review stages :-) . And they were all super minor and may have gone through unnoticed. Security Considerations: I'm wondering why CWT [RFC8392] was not used or recommended for signing. Is it that the other method fits better within SWIMA? COSE was chosen for CoSWID, since it is parallel to the use of XMLDSig.for SWID tags. We could consider CWTs, but this would require a bunch of additional work, and we are fairly close to shipping this draft to the IESG. Maybe a better option might be to write a second draft discussing the use of CWTs with CoSWID? This would allow this draft to move forward, while CWT use is defined. Would you be interested in working on this draft? Yes, I am interested, with coauthors. Are you offering? If CWTs are to be proliferated the way JWTs have been, I suspect it will be easier for CoSWID to gain traction. I think it would be good to list use of a CWT as an option, then registering the claims that one might use for let's say having the CWT be an EAT and be a remote attestation. I think adoption may be better if these are tied together and made simple for regular readers who will likely start to come across CWTs as opposed to just signing with one or more signers. I think what you have us good, but having both as options would be better. Both options would also create the need for some signature verifiers to support both options. This is something that should be discussed at greater length, as it could also create potential interoperability issues. I am not against both options, but we should talk to potential implementors about what they want. This is maybe more reason to do this work in a separate draft to allow for some time to work out these details.. OK, great point on interoperability. My hunch is that since CWTs are in EATs, there is code and there is an established pattern of use that this would be more likely to be supported (more widely). It may be good to pull this all out as not to create confusion as if it is int he base draft, this will be seen as necessary as opposed to a choice and as you note, will create confusion. The claims about the signature may vary from the data in the CoSWID, so this could be potentially useful. Right and minimal claims are possible too. Thanks, Kathleen True. Thank you! -- Best regards, Kathleen -- Best regards, Kathleen -- Best regards, Kathleen
_______________________________________________ sacm mailing list [email protected] https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C75ba45cd96ab47c1496808d76c23fd62%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637096774138403584&sdata=oifjgFqqiPGWeJIYV6nhg8EpZ3aNGhDh7wBS3sNxfJ0%3D&reserved=0
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
