If the work can be done in a WG, that is preferred. On Mon, Jan 9, 2017 at 2:38 PM, Justin Richer <[email protected]> wrote:
> +1 on the CURDLE question. > > -- Justin > > > > On 1/9/2017 1:13 AM, Jim Schaad wrote: > >> I just figure out that I sent this to the wrong list - maybe the names are >> too close together. >> >> -----Original Message----- >>> From: jose [mailto:[email protected]] On Behalf Of Jim Schaad >>> Sent: Sunday, January 01, 2017 3:34 PM >>> To: [email protected] >>> Cc: [email protected] >>> Subject: [jose] draft-jones-cose-rsa >>> >>> Comments: >>> >>> 0. Should this be done in curdle rather than as AD sponsored? >>> >>> 1. As per previous mail, remove values assignments in tables 1, 2, and 3 >>> >> unless >> >>> you have cleared them with the appropriate registry experts. I am less >>> >> worried >> >>> about table 4 but you should clear that as well. >>> >>> 2. Kill RSAES-OAP w/ SHA-1. We are not doing SHA-1 currently with any >>> of >>> >> the >> >>> CBOR algorithms. In section 3.1.1.1 - what are the properties that are >>> >> needed >> >>> here for SHA-1 so we can ensure that the statement is true. Also, rename >>> >> this to >> >>> be s/ SHA-1 not w/ Default. There are no defaults for COSE. >>> >>> 3. Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is >>> >> written. >> >>> 4. in the abstract be more specific about which RSA algorithms are being >>> supported. For example, you are not doing 1.5 or KEM. >>> >>> 5. Why does 3.1.1.1 have a size and 2.1.1 not have one. This should be >>> consistent. >>> >>> 6. section 3.1.1.1 should be encryption operation not decryption >>> >> operation. >> >>> 7. Section 3.1.1.1 - this text does not make sense "One potential denial >>> >> of >> >>> service >>> operation is to provide encrypted objects using either abnormally >>> long or oddly sized RSA modulus values." Should probably refer to >>> >> keys >> >>> not encrypted objects. >>> >>> 8. There is a requirement of minimum encoding lengths - what purpose >>> does >>> this serve? Is there a security problem here or is it just a nice to >>> have >>> >> because of >> >>> message size? >>> >>> 9. Missing some security considerations. >>> >>> 10 Section 2.1.1 s/hash functions are not truncated/hash function outputs >>> >> are >> >>> not truncated/ >>> >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >>> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- Best regards, Kathleen
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
