[cabfpub] Quantum Computing is now a concern.

[Tim Hollebeek]

So you would reject an international standard (ISO) that is not an RFC?  I think it would be a mistake to arbitrarily commit in advance to a particular standards body.  Pretty much everybody has started looking into this problem; it will be interesting to evaluate and compare the work products as they evolve.

I think the best guidance that can be given right now is that right now is one of the worst possible times to pick cryptographic algorithms and parameters and then bake it into a resource constrained device with a 10+ year lifetime with no ability to update.  Unfortunately, that's exactly what some sectors of the industry are planning to do ... IoT, I'm looking at you ...

For CA/Browser use cases, we're actually in better shape because most browsers have moved to a model where they update frequently and proactively.

-Tim

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Peter Bowen
Sent: Tuesday, July 12, 2016 8:55 PM
To: Robert Relyea; CABFPub
Subject: Re: [cabfpub] Quantum Computing is now a concern.


> On Jul 12, 2016, at 4:51 PM, Robert Relyea <rrelyea at redhat.com> wrote:
>
> On 07/12/2016 09:30 AM, Adam Langley wrote:
>>
>> I agree that we do not have a great post-quantum, public-key signature scheme available yet and that hash-based signatures are a good idea in some contexts.
>>
>> Did you envision that software would start supporting these signatures immediately? If so, then any certificate chains that take advantage of that would have to be hash-based from top to bottom because that's the only PQ primitive that would be supported. You've also specified a stateful signature scheme were doing things like moving a CA key from one HSM to another, or installing a leaf certificate on multiple servers, compromises the private key. (And that's assuming that there exist any HSMs that support hash-based signatures, which I don't think is the case.)
>
> I share Adam's concern here. We need to have standards defined and accepted and software needs to support these signatures before we start deploying them.

While I agree that it is very much time to be looking at Quantum-resistent algorithms, I share Bob's concerns and think that this highlights an opportunity for the Forum.  We do not have clear guidance for people who want to propose new algorithms to be included in the guidelines.  I think we should agree on some basic requirements that any algorithm should meet in order to be considered by the Forum.  Meeting these requirements does not guarantee acceptance, but any algorithm which does not meet these should not be considered until they are met.

I propose:

1) The public key information requirements must be defined in a published RFC.  This includes the format (e.g. ASN.1 for the Subject Public Key Info), Object Identifier(s), and any parameter validation requirements.

2) Guidance must exist on acceptable parameters.  For example, it might be valid to have a parameter that is 8 bits in size, but maybe current cryptographic strength recommendations call for 160 bits or more.

3) If the algorithm is proposed to use for signing certificate:
a) Requirements for private key storage are published.  This includes certification schemes for the storage systems.
b) The signature scheme for signing PKIX/X.509 objects is published in a RFC, including the applicable signatureAlgorithm object identifiers

4) At least one application supplied by Application Software Supplier (Browser) member of the Forum must implement the algorithm.

Thanks,
Peter
_______________________________________________
Public mailing list
Public at cabforum.org
http://scanmail.trustwave.com/?c=4062&d=_pGF17rx88CnnfOAfkSTsbNERkfhDL1Y93ltgtO0Cg&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.