Draft -02 incorporates the issue resolutions discussed below. Thanks again for
taking the time to do a thorough review, Jim. Replies describing specific
resolutions applied follow inline.
-- Mike
From: Jim Schaad [mailto:[email protected]]
Sent: Friday, January 13, 2017 9:47 PM
To: Mike Jones <[email protected]>; [email protected]
Cc: [email protected]
Subject: RE: draft-jones-cose-rsa
From: Mike Jones [mailto:[email protected]]
Sent: Friday, January 13, 2017 2:55 PM
To: Jim Schaad <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc:
[email protected]<mailto:[email protected]>
Subject: RE: draft-jones-cose-rsa
Thanks for taking the time to write this up, Jim. Responses are inline below.
-----Original Message-----
From: jose [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?
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.
[JLS] Getting people to from this old WG list can still be done even if it is
done in a different working group. That is what the idea of cross posting is
all about. Both individuals who have made substantive comments are on both
mailing lists anyway so doing in a different group does not close out either of
them. The amount of time a draft takes to finish depends as much on you as a
chair for most steps. It is possible that the Curdle group would not want the
draft, but asking is still reasonable.
[mbj] I seem to be getting useful feedback by posting the COSE list, as
Kathleen had suggested.
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.
I looked for the designated experts to consult with but the IANA COSE
registries don't seem to have been created yet, nor have the experts been
publicly named. Once they are, I will certainly consult with them. I don't
plan to remove the values since having proposed assignments is more useful to
implementers than having none.
[JLS] For interop testing - that is what the private values are for.
[mbj] I have left the proposed values in place, pending discussions with the
designated experts, once they are announced.
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.
RSAES-OAEP with the default parameters defined in Section A.2.1 of RFC 3447 is
included for the same reason that it is in RFC 7518 - because it's the mostly
widely implemented set of OAEP parameter choices, facilitating interoperation
of implementations. Particularly given that RSAES-PKCS1-v1_5 is not included,
RSA interop considerations lead to the decision to retain this algorithm.
In the next revision, I will be clear that the defaults come from RFC 3447.
[JLS] There is absolutely no reason to even say that default values exist here.
COSE does not have the concept of defaults. Not having SHA-1 does not seem to
be a problem for PSS, why would it be a problem here?
[mbj] As promised, I am now even clearer that they are RFC 3447-specified
defaults. The JOSE implementation experience with RSA-OAEP-SHA256 is that it's
not available on many development platforms, whereas RSA-OAEP is. Enabling
implementers to use the defaults has interop benefits for COSE, just like it
did for JOSE.
3. Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is written.
Suggestions for specific textual additions and/or changes would be helpful here.
[mbj] I have completely reworked and consolidated the Security Considerations
in ways intended to address this feedback.
4. in the abstract be more specific about which RSA algorithms are being
supported. For example, you are not doing 1.5 or KEM.
OK - will do
[mbj] Done
5. Why does 3.1.1.1 have a size and 2.1.1 not have one. This should be
consistent.
I agree with this suggestion. I'll make sure that the minimum size applies to
all uses of RSA algorithms.
[mbj] Addressed as part of restructuring the security considerations.
6. section 3.1.1.1 should be encryption operation not decryption operation.
OK
[mbj] It now says "cryptographic operation", because the guidance now applies
to signatures as well as encryption.
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.
OK
[mbj] Done (in reworked text)
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?
This is there for the same reason that it is present for JWKs - to facilitate
interoperation of implementations by having a standard representation for each
key, rather enabling a multiplicity of different representations to be used -
which could cause interop problems.
[JLS] Not sold.
[mbj] Having a standard representation also reduces the variance in data
formats that implementations have to parse, potentially improving interop.
Also, having a canonical representation has proven useful for JOSE. I will
likely prove useful for COSE for the same reasons.
9. Missing some security considerations.
Specific suggested text would be appreciated, as always.
[mbj] What would you like to see added?
10 Section 2.1.1 s/hash functions are not truncated/hash function outputs are
not truncated/
Agreed
[mbj] Done
Thanks again,
-- Mike
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
