Re: [COSE] Comments on draft-ietf-cose-hash-sig-01

[John Mattsson <[e-mail]>]

Thanks Russ,

Your suggested updates seems great.

>> - "The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two
>>   signature algorithm schemes."
>> 
>>    With RSA it is already three. Maybe remove this sentence?

>I am not talking about algorithms here.  I am talking about full signature and COSE_Sign0.

Ok, I see that the terminology is taken from Section 8 of RFC 8152:

   There are two signature algorithm schemes.  The first is signature
   with appendix.  In this scheme, the message content is processed and
   a signature is produced; the signature is called the appendix.  This
   is the scheme used by algorithms such as ECDSA and the RSA
   Probabilistic Signature Scheme (RSASSA-PSS).  (In fact, the SSA in
   RSASSA-PSS stands for Signature Scheme with Appendix.)

I do however find the terminology quite confusing as the term "scheme" is used on different levels. But that is more a comment for draft-ietf-cose-rfc8152bis-struct than draft-ietf-cose-hash-sig.

>> -  The other COSE Key types define how the the private and public key is stored in the COSE_Key structure. The HSS-LMS key type does not seem to do that, instead it only works as an identifier of the public/private key. I think the document should either
>> 
>>       - Define how to store the public key in the COSE_Key structure, or
>> 
>>       - Describe that the HSS-LMS key type is only an identifier and does not store the key pair. In that case I think the
>>         description "Description:  Public key for HSS/LMS hash-based digital signature" should be changed as well to
>>          include the word "identifier".
>    
>   Okay.  The public key is an octet string.  The internal structure of that octet string is summarized in Section 2.2, and it is fully specified in [HASHSIG].  Also, the IANA Considerations include a new entry in the "COSE Key Types" registry for the HSS/LMS public key.
>    
>> - As the algorithm and COSE_Key only contains the information "HSS-LMS@ and no information regarding the tree size and LM-OTS variant I assume the signer and verifier gets this information elsewhere (or does not need it). I think it would good if the draft shortly clarified this.
>    
>The signature value encodes that information as summarized in Section 2, and it is fully specified in [HASHSIG].

I have no doubt that the specification is correct, and that everything is fully specified in [HASHSIG]. BTW, Sections 2.1 - 2.3 give an excellent summary of HASHSIG. My feeling was just that some more short high level description would be helpful for developers implementing the draft. Such a developer would likely not have any understanding of [HASHSIG] and would likely take a [HASHSIG] implementation from the Internet and try to integrate it in their COSE implementation. Even for a developer that has previously implemented ECDSA or RSA signatures, [HASHSIG] works quite different as there are many public/private keys pairs and the public/private key pairs are not stored in the COSE_Key structure as with RSA and ECDSA.

I think it would be good if the draft gave some more guidance to a developer trying to integrate an existing HASHSIG library in their COSE implementation. But that is just a suggestion. I do not have strong feelings about this. I have not tried to actually implement it, and I do not yet have the detailed knowledge of HASHSIG to suggest what such guidance would actually say.

Cheers,
John

-----Original Message-----
From: Russ Housley <[e-mail]>
Date: Friday, 22 March 2019 at 07:40
To: John Mattsson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [COSE] Comments on draft-ietf-cose-hash-sig-01

    John:
    
    > Some high level comments below. I need to read draft-mcgrew-hash-sigs in more detail before giving more comments. 
    > 
    > - Section 1.1: I think some short info on the threat from Shor's algorithm would be good. I don't think [BH2013] talked about quantum computers.
    
    Right.  [BH2013] is about advances in cryptanalysis. [PQC] is about the consequences of a large-scale quantum computer.  I suggest:
    
       If large-scale quantum computers are ever built, these computers will
       be able to break many of the public-key cryptosystems currently in
       use.  A post-quantum cryptosystem [PQC] is a system that is secure
       against quantum computers that have more than a trivial number of
       quantum bits (qu-bits).  It is open to conjecture when it will be
       feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA
       are all vulnerable if large-scale quantum computers come to pass.
    
    > - Section 1.1: "RSA, DSA, and ECDSA are not post-quantum secure"
    > Add EdDSA to the list.
    
    As above.
    
    > - Section 1.1 " depend on discrete logarithm or factoring"
    > I suggestion "depend on the hardness of ... " or something similar.
    
    Yes, indeed.  I suggest:
    
       The HSS/LMS signature algorithm does not depend on the difficulty of
       discrete logarithm or factoring, as a result these algorithms are
       considered to be post-quantum secure.
    
    > - "The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two
    >   signature algorithm schemes."
    > 
    >    With RSA it is already three. Maybe remove this sentence?
    
    I am not talking about algorithms here.  I am talking about full signature and COSE_Sign0.
    
    > -  The other COSE Key types define how the the private and public key is stored in the COSE_Key structure. The HSS-LMS key type does not seem to do that, instead it only works as an identifier of the public/private key. I think the document should either
    > 
    >       - Define how to store the public key in the COSE_Key structure, or
    > 
    >       - Describe that the HSS-LMS key type is only an identifier and does not store the key pair. In that case I think the
    >         description "Description:  Public key for HSS/LMS hash-based digital signature" should be changed as well to
    >          include the word "identifier".
    
    Okay.  The public key is an octet string.  The internal structure of that octet string is summarized in Section 2.2, and it is fully specified in [HASHSIG].  Also, the IANA Considerations include a new entry in the "COSE Key Types" registry for the HSS/LMS public key.
    
    > - As the algorithm and COSE_Key only contains the information "HSS-LMS@ and no information regarding the tree size and LM-OTS variant I assume the signer and verifier gets this information elsewhere (or does not need it). I think it would good if the draft shortly clarified this.
    
    The signature value encodes that information as summarized in Section 2, and it is fully specified in [HASHSIG].
    
    > Nits:
    > 
    > "{{SHS}}"
    
    Fixed.
    
    Russ