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

Russ Housley <> Thu, 11 October 2018 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9B7A130EB9 for <>; Thu, 11 Oct 2018 09:08:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vsimDlpaQ21B for <>; Thu, 11 Oct 2018 09:08:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37259130EAC for <>; Thu, 11 Oct 2018 09:08:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E36FA300AA8 for <>; Thu, 11 Oct 2018 12:08:04 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id gh2Q_6NY-Yd4 for <>; Thu, 11 Oct 2018 12:08:00 -0400 (EDT)
Received: from new-host-5.home ( []) by (Postfix) with ESMTPSA id 4D13D300288; Thu, 11 Oct 2018 12:08:00 -0400 (EDT)
From: Russ Housley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EE0060AA-CDE8-4362-9406-45D805FB2935"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 11 Oct 2018 12:08:00 -0400
In-Reply-To: <>
Cc: SPASM <>
To: Daniel Van Geest <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
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 16:08:10 -0000

> On Oct 11, 2018, at 3:44 AM, Daniel Van Geest <> wrote:
> 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 do not mind putting this on the agenda at the end with the understanding that chartered work must take priority.  That way, if the work is added to the charter, the WG will be up to speed.  And, you might get useful comments 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 think the approach taken is fine.  The point is that the ASN.1 AlgorithmIdentifier does not carry any parameters.  All of the information that the verifier needs is encoded in the signature value, except the hash algorithm that is used to hash the TBScertificate.  That hash algorithm is part of the object identifier itself.

So, I was expecting something like this (picking just one of the hash-based signature algorithms, not all six):

      id-alg-hss-lms-hashsig  OBJECT IDENTIFIER ::= { iso(1)
            member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
            smime(16) alg(3) 17 }

      id-alg-hss-lms-hashsig-with-sha256  OBJECT IDENTIFIER ::= { iso(1)
            TBD1 }

      id-alg-hss-lms-hashsig-with-sha512  OBJECT IDENTIFIER ::= { iso(1)
            TBD2 }

      pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
          IDENTIFIER id-alg-hss-lms-hashsig
          KEY HSS-LMS-HashSig-PublicKey
          PARAMS ARE absent
              { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }

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

   sa-HSS-LMS-HashSig-with-SHA256 SIGNATURE-ALGORITHM ::= {
        IDENTIFIER id-alg-hss-lms-hashsig-with-sha256
        PARAMS ARE absent
        HASHES { mda-sha256 }
        PUBLIC-KEYS { pk-HSS-LMS-HashSig }
        SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha256 } }

   sa-HSS-LMS-HashSig-with-SHA512 SIGNATURE-ALGORITHM ::= {
        IDENTIFIER id-alg-hss-lms-hashsig-with-sha512
        PARAMS ARE absent
        HASHES { mda-sha512 }
        PUBLIC-KEYS { pk-HSS-LMS-HashSig }
        SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha512 } }

> 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.

Not completely.

sa-HSS-LMS-HashSig-with-SHA256 as defined above is the same as sa-HSS-LMS-HashSig in my draft.  We need to use one or the other.