Re: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-06.txt

[Russ Housley <[e-mail]>]

Daniel:

> Thanks for the clarification for me below, Jim.
>  
> Given that information, I wonder if it’s possible to misinterpret some parts of cms-hash-sig.
>  
> In section 3:
>  
>    The signature value is a large OCTET STRING.  The signature format is
>    designed for easy parsing.  Each format includes a counter and type
>    codes that indirectly providing all of the information that is needed
>    to parse the value during signature validation.
>  
> I think this paragraph is talking about the signature value as returned by the HSS algorithm.  In this case it’s not an OCTET STRING (i.e. the ASN.1 structure), but just an octet string. Referring to it as an OCTET STRING could result in confusion as to whether it’s double wrapped in ASN.1.

In RFC 5280 and X.509, the signature on a certificate is defined as:

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

This is the BIT STRING that Jim is talking about in his message.

In RFC 5652, the signature appears in SignerInfo:

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

      SignatureValue ::= OCTET STRING

This is the OCTET STRING that is being referenced in the quoted text.

> Similarly in section 4:
>  
>    The public key value is an OCTET STRING.  Like the signature format,
>    it is designed for easy parsing.  The value is the number of levels
>    in the public key, L, followed by the LMS public key.
>  
> While HSS-LMS-HashSig-PublicKey is actually an OCTET STRING, I think this paragraph is referring to the public key as processed by HSS and so should be an octet string.

That test is referring to this part of the ASN.1:

   HSS-LMS-HashSig-PublicKey ::= OCTET STRING

Russ


> On 2019-03-05, 2:34 PM, "Jim Schaad" <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
>  
> From: Daniel Van Geest <[e-mail] <mailto:[e-mail]>> 
> Sent: Tuesday, March 5, 2019 10:20 AM
> To: Jim Schaad <[e-mail] <mailto:[e-mail]>>; 'Russ Housley' <[e-mail] <mailto:[e-mail]>>
> Cc: 'SPASM' <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-06.txt
>  
>  
>  
> On 2019-03-05, 12:50 PM, "Jim Schaad" <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
>  
> From: Spasm <[e-mail] <mailto:[e-mail]>> On Behalf Of Daniel Van Geest
> Sent: Tuesday, March 5, 2019 8:38 AM
> To: Russ Housley <[e-mail] <mailto:[e-mail]>>; Jim Schaad <[e-mail] <mailto:[e-mail]>>
> Cc: SPASM <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-06.txt
>  
> I’m working to align x509-hash-sigs draft and implementations with this one.  There’s something in cms-hash-sigs that I’d like clarification on to understand the implications.
>  
> The ASN.1 module defines:
>  
>       pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
>           IDENTIFIER id-alg-hss-lms-hashsig
>           KEY HSS-LMS-HashSig-PublicKey
>           PARAMS ARE absent
>           CERT-KEY-USAGE
>             { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
>  
>       HSS-LMS-HashSig-PublicKey ::= OCTET STRING
>  
> Specifically, the public key is an OCTET STRING. The actual public key is “u32str(L) || lms_public_key”, so essentially an opaque octet string.
>  
> What are the implications in x.509 of defining “HSS-LMS-HashSig-PublicKey ::= OCTET STRING”?  Does this mean that in the Subject Public Key Info attribute, the HSS public key would be encoded as an OCTET STRING which is then wrapped in a BIT STRING encoding? (as opposed to a BIT STRING encoding of the raw “u32str(L) || lms_public_key” octet string).
>  
> The closest I could find to this situation is Ed25519/Ed448 since those public keys are also just raw octet strings (32 octets in 25519).  But the ASN.1 module for RFC 8410 specifies “-- KEY no ASN.1 wrapping --” within PUBLIC-KEY:
>  
>     pk-Ed25519 PUBLIC-KEY ::= {
>         IDENTIFIER id-Ed25519
>         -- KEY no ASN.1 wrapping --
>         PARAMS ARE absent
>         CERT-KEY-USAGE {digitalSignature, nonRepudiation,
>                         keyCertSign, cRLSign}
>         PRIVATE-KEY CurvePrivateKey
>     }
>  
> I’m not an ASN.1 expert, so could someone explain the difference? Is the “no wrapping” there because the public key is raw octets? And then whoever encodes the public only applies their own encoding (if any) of the octets.  Does it have to do with the fact that the public key can be easily derived from the private key?  Is my assumption correct that a SPKI encoding of an HSS key would be a BIT STRING encoding of an ASN.1 OCTET STRING encoding of the raw octets?
>  
> [JLS] As I read this what you have deduced is correct.  For Ed25519 the public key is directly wrapped in the BIT STRING with no additional encoding.  For the hash sig public key the public key is wrapped in an OCTET STRING which is then wrapped in the BIT STRING.  
>  
> As a general rule, I prefer having the extra layer of ASN.1 encoding because a lot of decoders assume that there is going to be that layer when processing certificates.  However, I did not write the initial versions of the Edwards draft and thus I just used the encoding that was there rather than writing it as I would prefer.
>  
> [DVG] Do you prefer this general rule for the signature as well?  In X.509 would you prefer the raw signature octets wrapped in an OCTET STRING wrapped in a BIT STRING?  How would this work in CMS where the signature field within the SignerInfo is already defined as an OCTET string? Wouldn’t the rule imply the raw HSS octet string wrapped in an OCTET STRING wrapped in an OCTET STRING? That’s not how I’m reading cms-hash-sigs, e.g. section 5:
> 
>       signature contains the single HSS signature value resulting from
>          the signing operation as specified in [HASHSIG].
>  
> And `signature` already being defined as an OCTET STRING make this read to me as a single wrapping.
>  
> [JLS] Signatures have traditionally always been the raw bytes.  The difference is that frequently public and private keys have had ASN.1 structure wrapped around them while signatures have not.  For an example look at how RSA is done.
>  
> Jim
>  
>  
> Thanks,
> Daniel
>  
> Jim
>  
>  
> Thanks,
> Daniel
>  
> On 2019-02-27, 12:27 PM, "Spasm on behalf of Russ Housley" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:
>  
> Jim:
>  
> You are correct.  I missed this when I made the last update.  I will make the change now in my edit buffer.  I'll post it along with any other changes that result from IETF Last Call.
>  
> Russ
>  
>  
> On Feb 26, 2019, at 8:25 PM, Jim Schaad <[e-mail] <mailto:[e-mail]>> wrote:
> I have a small change to request.  I am happy if you deal with it at a later
> date as long as it does not get lost.
> In the ASN.1 module, the SIGNATURE-ALGORITHM definition should have an empty
> or absent HASHES field.  There are no hash functions which are to be applied
> prior to given the input to the signing function.  This would match what I
> did for EdDSA.
> Jim
> -----Original Message-----
> From: Spasm <[e-mail] <mailto:[e-mail]>> On Behalf Of Russ Housley
> Sent: Tuesday, February 26, 2019 10:44 AM
> To: SPASM <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-06.txt
> This removes the extraneous paragraph that was pointed out by Daniel.
> I believe that all comments have been resolved, and the document is now
> ready to go to the IESG.
> Russ
> On Feb 26, 2019, at 1:41 PM, [e-mail] <mailto:[e-mail]> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Limited Additional Mechanisms for PKIX
> and
> SMIME WG of the IETF.
>        Title           : Use of the HSS/LMS Hash-based Signature
> Algorithm in the
> Cryptographic Message Syntax (CMS)
>        Author          : Russ Housley
>                 Filename        : draft-ietf-lamps-cms-hash-sig-06.txt
>                 Pages           : 14
>                 Date            : 2019-02-26
> Abstract:
>   This document specifies the conventions for using the the HSS/LMS
>   hash-based signature algorithm with the Cryptographic Message Syntax
>   (CMS).  In addition, the algorithm identifier and public key syntax
>   are provided.  The HSS/LMS algorithm is one form of hash-based
>   digital signature; it is described in [HASHSIG].
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ <https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-06 <https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-06>
> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-06 <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-06>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-hash-sig-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-hash-sig-06>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org <http://tools.ietf.org/>.
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>