I had requested AD sponsorship because of how simple the draft is. It
registers a few numbers in registries being created by the COSE Messages draft
and defines the layout of RSA keys (in a way that’s completely parallel to the
JOSE layout, but using CBOR rather than JSON). It uses no new algorithms. It
didn’t seem to rise to the occasion of needing a working group – especially
when there remain COSE WG members such as Jim willing to take the time to give
constructive feedback.
BTW, I plan to respond to Jim’s note in detail later in the week. For the
first half of the week, I’m on another medical sojourn for my wife in Boston.
Cheers,
-- Mike
From: COSE [mailto:[email protected]] On Behalf Of Kathleen Moriarty
Sent: Monday, January 9, 2017 11:50 AM
To: Justin Richer <[email protected]>
Cc: Jim Schaad <[email protected]>; cose <[email protected]>
Subject: Re: [COSE] FW: [jose] draft-jones-cose-rsa
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]<mailto:[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]<mailto:[email protected]>] On
Behalf Of Jim Schaad
Sent: Sunday, January 01, 2017 3:34 PM
To:
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
--
Best regards,
Kathleen
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
