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 <jricher@mit.edu> 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:jose-bounces@ietf.org] On Behalf Of Jim Schaad
>>> Sent: Sunday, January 01, 2017 3:34 PM
>>> To: draft-jones-cose-rsa@tools.ietf.org
>>> Cc: jose@ietf.org
>>> 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
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>> _______________________________________________
>> COSE mailing list
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinfo/cose
>>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>

-- 

Best regards,
Kathleen