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

From: Daniel Van Geest <[email-masked]>
Date: Wed, 10 Oct 2018 18:18:19 +0000

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.

Thanks,

Daniel

On 2018-10-10, 8:14 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> 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
URL:            https://www.ietf.org/internet-drafts/draft-vangeest-x509-hash-sigs-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vangeest-x509-hash-sigs/
Htmlized:       https://tools.ietf.org/html/draft-vangeest-x509-hash-sigs-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vangeest-x509-hash-sigs

Abstract:
   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 tools.ietf.org.

The IETF Secretariat

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 Oct 2018 16:19:29 -0400

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

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

Russ

> On Oct 10, 2018, at 2:18 PM, Daniel Van Geest <[email-masked]> wrote:
> 
> On 2018-10-10, 8:14 PM, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
> URL:            https://www.ietf.org/internet-drafts/draft-vangeest-x509-hash-sigs-00.txt <https://www.ietf.org/internet-drafts/draft-vangeest-x509-hash-sigs-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-vangeest-x509-hash-sigs/ <https://datatracker.ietf.org/doc/draft-vangeest-x509-hash-sigs/>
> Htmlized:       https://tools.ietf.org/html/draft-vangeest-x509-hash-sigs-00 <https://tools.ietf.org/html/draft-vangeest-x509-hash-sigs-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-vangeest-x509-hash-sigs <https://datatracker.ietf.org/doc/html/draft-vangeest-x509-hash-sigs>
>  
>  
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>  
> The IETF Secretariat
>  
>  
> _______________________________________________
> Spasm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: Daniel Van Geest <[email-masked]>
Date: Thu, 11 Oct 2018 07:44:12 +0000

On 2018-10-10, 10:19 PM, "Russ Housley" <[email-masked]<mailto:[email-masked]>> wrote:

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’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?

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.

Russ

On Oct 10, 2018, at 2:18 PM, Daniel Van Geest <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Daniel

Abstract:

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

The IETF Secretariat

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Oct 2018 12:08:00 -0400

> On Oct 11, 2018, at 3:44 AM, Daniel Van Geest <[email-masked]> wrote:
> 
>  
>  
> On 2018-10-10, 10:19 PM, "Russ Housley" <[email-masked] <mailto:[email-masked]>> wrote:
>  

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 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 di…

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
          CERT-KEY-USAGE
              { 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’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.

Russ

---

From: Daniel Van Geest <[email-masked]>
Date: Sun, 14 Oct 2018 02:19:52 +0000

On 2018-10-11, 12:08 PM, "Russ Housley" <[email-masked]<mailto:[email-masked]>> wrote:

Right.  Well since this draft proposes a SHA-512 variant, I think the SHA-256 variant should have SHA256 in the name (using a similarly-named OID).  It would be cleanest if the OIDs were all defined in the same document and other docs reference the one, but am not opposed if there are reasons for doing it otherwise.  That’s something to determine if this gets added to the charter.

Russ