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

[Jim Schaad <[e-mail]>]

 

 

From: Spasm <[e-mail]> On Behalf Of Daniel Van Geest
Sent: Tuesday, March 5, 2019 8:38 AM
To: Russ Housley <[e-mail]>; Jim Schaad <[e-mail]>
Cc: SPASM <[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.

 

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.

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