Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

[Mike Ounsworth <[e-mail]>]

Thanks Panos for laying out the use-cases. I think you hit a bit one on the head: FIPS approval. On 2019-10-30, NIST published a PQC FAQ that includes a call for hybrid modes for both key exchange and signatures.
https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs
draft-ounsworth-pq-composite-sigs intends to be the “obvious” implementation of NIST’s call for hybrid modes.


One place that we differ from NIST’s call is this point in the FAQ:

> The mode is valid if and only if both signatures are valid.

One of the design requirements that we’ve been working with is the one pushed by Max Pala / CableLabs; deploy devices in the field today that understand the hybrid pub key / signature format, but do not necessarily have an implementation of the PQ algorithm (or have an older, incompatible, implementation of the PQ alg while the NIST PQC is still shaking out mathematical or implementation vulnerabilities).


As to the philosophical debate about “Keep X.509 or go to something new?”, note that draft-ounsworth aims to define composite public key and signature formats that, if we’ve done it right, are compatible with any ASN.1 protocol. This draft is intentionally decoupled from, but can be used by, X.509.  The goal here is not to


Re: hash-based signatures: For a CA vendor – whether providing publicly-trusted services, or on-prem software -- product capabilities are driven by the industry; if the industry is happy with pure hash-based PKI during the transition period, then I agree that hybrid modes are unnecessary. However, that’s not what I’m seeing: the HBS schemes currently available in IETF are all stateful, and 1) NIST’s SP 800-208-draft says “Stateful HBS schemes are not suitable for general use because they require careful state management that is often difficult to assure”, and 2) chats I’ve had with Ryan Sleevi and Adam Langley who seem skeptical that all CA operators (public, private, corporate, etc), can responsibly manage a stateful private key. 3) Earlier this year, Panos had been pushing for publicly-trusted HSB root CAs, but dropped it on the point that, once you have a stateful HBS root CA, what do you do with it? You don’t really want end entities (TLS servers, the S/MIME client on your phone, PIV cards, etc) using stateful keys.
So maybe the market will be satisfied with HBS-only PKIs for some use-cases, but I maintain that we should standardize a fully algorithm-agnostic hybrid mechanism anyway.



PS - I’ll take your bait on the “corner the market” comment; IMHO a PKI is useless if its core functionality – public keys and signatures --do not interoperate with other vendors. No cornering of the market is intended, simply looking for a simple-ish solution quickly-ish.

---
Mike Ounsworth
Software Security Architect, Entrust Datacard

From: Secdispatch <[e-mail]> On Behalf Of Panos Kampanakis (pkampana)
Sent: December 12, 2019 9:56 PM
To: Eric Rescorla <[e-mail]>; Stephen Farrell <[e-mail]>; Michael Richardson <[e-mail]>
Cc: IETF SecDispatch <[e-mail]>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

Hi Ekr, Stephen, Mike,


> As a variation of what EKR asked, you are asking for PQ-PKI, but your use case is image signing.

UEFI Secure Boot (in essence what I meant by image singing)  uses a PKI architecture. There is a Product Key PK (root CA) that establishes a trust relationship between the platform owner and the platform firmware. The PK signs KEKs which established a trust relationship between the platform firmware and the operating system. These are mostly in X.509 today. More in [2].

> Is there a reason why you don't want to do hash signatures?

HBS indeed looks like the best option for this usecase. Not necessarily stateful. We have some preliminary analysis on this is in Section 3 in [1]. More to come soon.

But we can’t go directly to pure HBS because already deployed machines in the field will not boot at all and upgrading BIOS is not simple. Also, we can’t go to pure HBS because it will not be FIPS approved even after we have a standardized PQ option. So, we have to do some sort of composite RSA+post-quantum (NIST has put out a statement that says that a composite will still be FIPS approved if the classical part is). The FIPS argument is important. Waiting for PQ standardization is one thing, but FIPS approval will take even longer and until then we (Cisco) want to do some sort of composite before then.

Note that I am not interested in getting an X.509 OID for RSA+HBS, I want a definition of how composite would work so I can establish the requirements for these future chips supporting composite verification.


> It's not at all clear to me that data integrity nor origin authentication in that timeframe ought be tied to x.509 certificates at all.

Stephen’s comment about not doing it in X.509 is valid. We could use a composite blob and use it in our own custom way. Two issues with that:

  1.  UEFI chains of trust have been moving to X.509 and to CMS/PKCS#7 for the sw signatures. I am not claiming there are no custom keys/signature formats nowhere, but most UEFI vendors have been moving away from them. So going to custom key representations or COSE would be a step backwards or sideways.
  2.  Also OEM vendors that include sig verification in their chips or FPGAs show preference in well-defined specs probably because they can reuse them for other usecases.
That is why we (Cisco) would prefer to see a standard way of doing composite sigs for UEFI (in X.509 and in CMS to be honest) instead of defining our own. We probably don’t want to solve this many times, once by each vendor, once in CMS, once UEFI PKI.

I totally appreciate the counter-argument about complexity and potential cans of worms, but I am afraid vendors will have to address this either individually or as a group. And my argument would doing it as a group.

Rgs,
Panos

[1] https://eprint.iacr.org/2019/1276.pdf
[2] https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance



From: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, December 12, 2019 11:52 AM
To: Panos Kampanakis (pkampana) <[e-mail]<mailto:[e-mail]>>
Cc: Stephen Farrell <[e-mail]<mailto:[e-mail]>>; IETF SecDispatch <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (



On Thu, Dec 12, 2019 at 8:33 AM Panos Kampanakis (pkampana) <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

> Sorry if I've missed it, but who do we have that is calling for a post-quantum PKI solution to be developed now, but who is not promoting one such?

We (Cisco) will need PQ PKI (not WebPKI) solution for image signing. When talking about chips that are designed now and will live in the field for decades, we would like to design today instead of wait for 2030. Note we are spending (not making) money on PKI, so we are not trying to corner a market.

Is there a reason why you don't want to do hash signatures?

-Ekr

I have talked to another vendor interested in them to sign its OS but I will not speak for them. I have also talked to at least one HSM vendor that has some clients asking for PQ PKI support to be added in their HSM but I will not speak for them either. I don't think any of these use-cases are trying to corner a market.

Panos


-----Original Message-----
From: Secdispatch <[e-mail]<mailto:[e-mail]>> On Behalf Of Stephen Farrell
Sent: Sunday, December 08, 2019 9:04 PM
To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Dr. Pala <[e-mail]<mailto:[e-mail]>>
Cc: IETF SecDispatch <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (


Hiya,

Cutting to the nub of my concern...

On 09/12/2019 01:46, Mike Ounsworth wrote:
> I hope that doesn’t preclude a push for a more immediate solution.

ISTM the "push" is less for a solution than for understandably attempting to corner a market. I don't think such attempts are "bad" things, but I do think following 'em is more likely unwise.

Sorry if I've missed it, but who do we have that is calling for a post-quantum PKI solution to be developed now, but who is not promoting one such?

Thanks,
S.
_______________________________________________
Secdispatch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/secdispatch