[cabfpub] Quantum Computing is now a concern.

Wed Jul 13 17:27:02 UTC 2016

What I am proposing is contingency planning. We have two unknowns:

1) How fast QC will advance
2) Whether QCR public key will advance fast enough to allow a seamless transition.

The stall in Moore’s law means that we are going to see a lot of R&D that is currently focused on traditional VLSI looking for new areas to study. It only takes one large QC computer to ruin everything. It also means that the traditional concern about an improvement in factoring may be less of an issue. Combined it seems that the advice from NIST to focus on QCR rather than transition away from RSA looks sound.

I don’t think we can risk depending on unknown 2 working in our favor and the problem resolving itself. And even if it does we are going to be in for a bumpy ride with devices that can’t be upgraded.

The hash signature approach you take depends on how confident you are in your assessments of #1 and #2.

I am assuming that these are both complete unknowns and so I am looking only at the use of hash signatures to effect a bootstrap at this stage. I am also assuming that CAs know how to use statefull signatures without shooting themselves in the foot. I don’t much care about the size of the public key as the trust root only needs to be a fingerprint of the public key.

That is not a full QCR PKI or even close, that is only a bootstrap. I would like to have as much bootstrap as possible pre-deployed because if we do end up in a panic situation, the fewer moving parts, the better. It is likely to take a year for the CA industry to make whatever infrastructure changes are required to deploy QCR PKI even on an emergency basis. It is likely to take a year for the browsers to move as well. If we preplan, we may be able to do this work in parallel. If we don’t we are likely to find that it takes two years.

This is not an IPv6 type situation. If we hit a crunch we are going to have a lot of governments very nervous very quickly.

As for IoT, the other side of preplanning is to tell folk that if their systems don’t have a QCR strategy, they should not be considered secure. But they won’t care about that right now as virtually all the systems are being built as liability magnets.

> On Jul 13, 2016, at 9:50 AM, Tim Hollebeek <THollebeek at trustwave.com> wrote:
> 
> 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> [mailto: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 <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.
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public <https://cabforum.org/mailman/listinfo/public>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160713/ea3eecf7/attachment-0003.html>