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

[Daniel Van Geest <[e-mail]>]

Russ,

I understand what they are referring to, but when the paragraph begins “The (signature, public key) value is an OCTET STRING” and then goes on to describe it as (designed for easy parsing, including a counter and type codes, the number of levels followed by the key), all of which describe the HSS algorithm signature’s contents, one might also read the first sentence as referring to the HSS algorithm’s signature.

It’s just a nit, and if you don’t agree that one could end up reading those paragraphs that way, then they’re fine as is.

Thanks,
Daniel


On 2019-03-10, 1:17 AM, "Russ Housley" <[e-mail]<mailto:[e-mail]>> wrote:

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/
There are also htmlized versions available at:
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
A diff from the previous version is available at:
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/