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

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

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?

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.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm
_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm

_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm