Re: [lamps] FW: New Version Notification for draft-vangeest-x509-hash-sigs-00.txt

Daniel Van Geest <> Thu, 11 October 2018 07:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE634130E63 for <>; Thu, 11 Oct 2018 00:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eWTRf_1eohLo for <>; Thu, 11 Oct 2018 00:44:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1887E130DE1 for <>; Thu, 11 Oct 2018 00:44:16 -0700 (PDT)
Received: from unknown (HELO ([]) by with ESMTP; 11 Oct 2018 07:44:13 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1466.3; Thu, 11 Oct 2018 03:44:12 -0400
Received: from ([fe80::d802:5aec:db34:beba]) by ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1466.003; Thu, 11 Oct 2018 03:44:12 -0400
From: Daniel Van Geest <>
To: Russ Housley <>
Thread-Topic: [lamps] FW: New Version Notification for draft-vangeest-x509-hash-sigs-00.txt
Thread-Index: AQHUYMUHdpxjfrA1dEW3V6hKK1/0vaUZLkUAgAAAV4CAAODWAA==
Date: Thu, 11 Oct 2018 07:44:12 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_97CFF9D6F4454FD4A0FF4296F580C5DFisaracom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [lamps] FW: New Version Notification for draft-vangeest-x509-hash-sigs-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Oct 2018 07:44:30 -0000

On 2018-10-10, 10:19 PM, "Russ Housley" <<>> wrote:

I suspect that this document will need to go through secdispatch in order to get the LAMP WG charter updated.

Ok, I will post this draft to secdispatch as well and request a presentation slot in Bangkok.  Then I suppose I should wait until March to present to LAMPS depending on the Bangkok results, or should I present to LAMPS in Bangkok too?

I skimmed the document, and it defines object identifiers for the algorithms, put it should probably use SIGNATURE-ALGORITHM as defined in RFC 5912.  That way, it is clear that all 6 algorithm identifiers are used without parameters.

I’ll make this change in the next version.

I think it’s worth bringing up something about the parameters of these signature schemes here.  XMSS(^MT) only has a single parameter and it’s encoded as the first 4 bytes of the public key, so it’s easy for the verifier to decode.  But HSS is more complicated.  An HSS private key has multiple levels of LMS trees, and each LMS tree can have different parameters (winternitz and height, and in theory hash algorithm and possibly truncated length, depending on what Scott does with a follow-up HSS draft).  The public key only encodes the number of levels and the parameters of the first-level LMS tree.  The parameters for the LMS trees in the other levels are only encoded in the signature.

I don’t think we should mandate that all HSS certificate (and CMS) signing keys use the same parameters for all levels because there’s valid reasons to use at least different LMS tree heights on different levels (which Scott has justified elsewhere, I could dig it up if desired).  Given that, is there a reason why a verifier would need the full parameters set for all levels before they’ve received the signature?  If so, and as ugly as it would be, would we have to encode all the parameters in the SIGNATURE-ALGORITHM?

I would like to see certificates and CMS uses the same object identifiers for the public keys and the signatures in all cases.  We need to do some coordination to make sure that happens.

Ah, I didn’t realize that signatureAlgorithm could be an algorithm ID that doesn’t have an attached digest algorithm, or an algorithm ID that has an attached digest algorithm, with the digest algorithm being set in digestAlgorithm at the same time.  Makes sense that the OIDs for CMS and certificates are the same in this case.

I’m already using the HSS public key OID from your CMS draft so CMS and certificates would be aligned here.


On Oct 10, 2018, at 2:18 PM, Daniel Van Geest <<>> wrote:

My employer has seen interest in hash-based signatures for X.509 certificates and is implementing support for them.  This draft adds signature algorithm identifiers for HSS (the key identifier is already defined in draft-ietf-lamps-cms-hash-sig), and key and signature algorithm identifiers for XMSS and XMSS^MT.

Due to their statefulness, these hash-based signatures are not appropriate for EE certs in interactive protocols, but are useful in CA certs and code signing.  Because of the long time needed to deploy CA certs, the potential long life of signed code, and the fact that hash-based signatures are already considered to be secure, it is prudent to enable deployment of hash-based certificates now rather than waiting for the NIST competition to select a PQ signature scheme.

This is a relatively simple draft, basically just assignment of OIDs.  Is there interest in this group for this draft?  If not, should it be an Individual Submission?  I can post this to Secdispatch for their opinion too.

A few other notes on the draft:
- It needs to align KeyUsage with draft-ietf-lamps-cms-hash-sig (this draft currently has MUSTs for the values, while the other has MAYs).
- id-alg-hss-lms-hashsig is repeated from ietf-lamps-cms-hash-sig.  All other OIDs are assigned from ISARA’s arc.  If instead there is a preferred arc to request OIDs from we can look into that.

Any feedback from the group would be appreciated.


On 2018-10-10, 8:14 PM, "<>" <<>> wrote:

A new version of I-D, draft-vangeest-x509-hash-sigs-00.txt
has been successfully submitted by Daniel Van Geest and posted to the
IETF repository.

Name:                   draft-vangeest-x509-hash-sigs
Revision:              00
Title:                      Algorithm Identifiers for HSS and XMSS for Use in the Internet X.509 Public Key Infrastructure
Document date:                2018-10-10
Group:                  Individual Submission
Pages:                   13

   This document specifies algorithm identifiers and ASN.1 encoding
   formats for the Hierarchical Signature System (HSS), eXtended Merkle
   Signature Scheme (XMSS), and XMSS^MT, a multi-tree variant of XMSS.
   This specification applies to the Internet X.509 Public Key
   infrastructure (PKI) when digital signatures are used to sign
   certificates and certificate revocation lists (CRLs).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>g/>.

The IETF Secretariat

Spasm mailing list<>