Re: [lamps] draft-gazdag-x509-hash-sigs-00

One more comment regarding draft-gazdag-x509-hash-sigs. 

Stateful HBS had come up previously for X.509 and some participants voiced serious concerns https://mailarchive.ietf.org/arch/msg/spasm/DKPDfaQZxF5_De9BYuoWsRKp4gM/ A summary of the counter-arguments could be that CAs have messed up before, how can we rest assured they will not reuse state. 

I think your argument for Stateful HBS in this draft is only for root CAs which sign a few ICAs and then go to sleep and rarely wake up. Maybe another use is for code-signing EKU certs where the signer controls its signing process and the verifiers trust it.  The draft also mentions subordinate CA certificates. I don't think these are good use-cases for stateful HBS. I would suggest for the draft to clearly stress the potentially use-cases for Stateful HBS. Also I suggest for the security considerations section to stress the importance and how you envision these use-cases will be able to address the state concern. For example a Root CA uses an HSM and signs very few ICA certs and then goes offline. Another example is a code-signer keeps track of all its signatures and can go back and attest the state was not reused periodically and its verifiers usually trust the signer. Another one could be the state look ahead where you retrieve x states and change your pointer before you even start signing anything.

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Kousidis, Stavros
Sent: Saturday, December 24, 2022 12:11 AM
To: Russ Housley <housley@vigilsec.com>
Cc: LAMPS <spasm@ietf.org>; draft-gazdag-x509-hash-sigs.authors@ietf.org
Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Dear Russ,

thank you for the information.

In the next version we will adopt the "OCTET STRING" definition of RFC 8708 for HSS and apply this also to XMSS/XMSS^MT. The same applies to SPHINCS+ where we will adopt the definition of "draft-ietf-lamps-cms-sphincs-plus-01".

Best
Stavros

-----Ursprüngliche Nachricht-----
Von: Russ Housley <housley@vigilsec.com>
Gesendet: Freitag, 23. Dezember 2022 18:12
An: draft-gazdag-x509-hash-sigs.authors@ietf.org
Cc: LAMPS <spasm@ietf.org>
Betreff: [lamps] draft-gazdag-x509-hash-sigs-00

Dear I-D Authors:

RFC 8708 has this definition:

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

This will carry the bytes as defined in RFC 8554.

draft-gazdag-x509-hash-sigs-00 says:

    HSS-HashSig-PublicKey ::= SEQUENCE {
       levels     OCTET STRING, -- number of levels L
       tree       OCTET STRING, -- typecode of top-level LMS tree
       ots        OCTET STRING, -- typecode of top-level LM-OTS
       identifier OCTET STRING, -- identifier I of top-level LMS key pair
       root       OCTET STRING  -- root T[1] of top-level tree
    }

This will produce a different byte string than RFC 8554.  I think this is a problem.  There should only be one way to encode the HSS/LMS public key.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm