[cabfpub] Quantum Computing is now a concern.

[philliph at comodo.com]

Well obviously we can’t move forward without an agreed upon standard. Which is why this isn’t just an issue for the browser providers.

The forum is really not the issue, wherever we decide to discuss it will be the forum. The advantage of using IRFT/IETF for this particular discussion is that most of us already know how it works. It is also fairly easy to call an interim or preparatory meeting under IETF Note Well and keep the IPR situation straight.

There is already a proposal for a Lamport signature specification in IRTF. And there is a specification for use of Merkle Tree algs in CMS. 

https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/ <https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/>
https://tools.ietf.org/html/draft-housley-cms-mts-hash-sig-03 <https://tools.ietf.org/html/draft-housley-cms-mts-hash-sig-03>

Now these may or may not meet our needs. It is not even clear what our needs are at this point. 

Peter’s list looks like the sort of thing that the IETF Security ADs are going to find very useful in deciding whether this is work IETF or IRTF should spend time on. And while they do not make decisions on what IRTF works on, the decision to move work from IRTF to IETF is their call.



> On Jul 12, 2016, at 8:55 PM, Peter Bowen <pzb at amzn.com> wrote:
> 
>> 
>> 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 <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/f25c4430/attachment-0003.html>