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

["Panos Kampanakis (pkampana)" <[e-mail]>]

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