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

[Mike Ounsworth <[e-mail]>]

Hi Ekr, Max, Stephen,

We tried to design the proposed CompositeCrypto solution to be as generic and general as possible. During design, we wanted something that would work “generically well” across all ASN.1-based use-cases: PKIX (X.509, CRL, CMP, CMS S/MIME), OCSP , PKCS#?, PIV smart cards, code-signing, etc.

As Max said, it’s certainly possibly to design a more elegant solution by tailoring it to one use-case (for example by considering mechanisms available in a negotiated protocol). However, as companies who implement general-purpose Certificate Authorities, we’re looking for a more one-size-fits-most solution.

If WebPKI and CA/B Forum wants to take more time -- possibly even waiting out this problem – I hope that doesn’t preclude a push for a more immediate solution.


As for “why now”: Max has spoken at length about DOCSIS cable modems who want to begin deploying multi-algorithm-capable devices, like now. There are also other closed PKI environments (think heterogenous corporate PKIs providing certs for email, physical building access, Windows smart-card login, etc) where the customer-demanded timelines for classical+PQ solutions are too short to wait for each problem domain to standardize an optimized multi-alg cert standard (plus think of the headache if we fracture into dozens of different cert formats!).

As you say Ekr, maybe the solution is to use hash-based until we’re ready to migrate wholesale to a single NIST-crowned algorithm, but this is not the opinion that I’m hearing from the community around the NIST PQC, nor from my customers who want greater agility, not more restrictions. Hence this generic and flexible CompositeCrypto draft.


TL;DR: CompositeCrypto may not be the forever solution for all use-cases, but it would give us something we can start using soon as a transition mechanism, that we have confidence will be relatively problem-free across the breadth of PKI problem spaces.

- - -
Mike Ounsworth

From: Secdispatch <[e-mail]> On Behalf Of Eric Rescorla
Sent: Wednesday, November 20, 2019 1:29 AM
To: Dr. Pala <[e-mail]>
Cc: IETF SecDispatch <[e-mail]>; Stephen Farrell <[e-mail]>
Subject: [EXTERNAL]Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Hi Max,

I'm not presently taking a position on whether this work should proceed in a general matter; I haven't thought it through enough to have an opinion.

What I was trying to say in the meeting is that I don't think this is probably to be of much use in the WebPKI at this time.

-Ekr


On Tue, Nov 19, 2019 at 11:22 PM Dr. Pala <[e-mail]<mailto:[e-mail]>> wrote:

Hi Stephen, all,

I just want to add a quick consideration here. We work with hardware that is deployed at the customer's homes, offices, etc. When planning for our innovation to hit the networks, we need to plan years in advance - this is not something we deal with in universities, but, I assure you, it requires a lot more planning than you might be used to.

I do disagree with the fact that what we are doing doesn't really help that much. The proposed approach does provide a solution that, although it might not be optimized, it works.

Other solutions might come afterwards that provide (probably more complex) optimized paths (maybe TLS 2.0 will be quite different because its design will cover the new design requirements). Another possibility is that application specific would define their own code points: the "CompositCrypto" algorithm OID will allow to combine any algorithms. Applications can then define their own code-points that they accept by simply defining the appropriate OID for the algorithm identifer. For example, when and if TLS, for example, would like to define its own combination of algorithms, a set of specific code-points can be defined for that.

Coming back to delaying the work - I think it is wrong and I would like to understand why you think it is a good idea.

  *   We have the interest of an industry sector
  *   Plus, there has been support on the MLs for not delaying the work any further
  *   Plus, this work is presented by a committed set of Companies that have real interest in using this technology to protect the PKIs that secure the internet connectivity for hundreds of millions of users.
  *   Plus, the problem has been already addressed in other institutions (ITU-T) - thus indicating that IETF is falling behind on this topic.
  *   Plus, we are in contact with NIST to possibly collaborate on real-world deployment of QRC by using Composite Crypto.

I think that blocking or stalling this work within the IETF does not make any sense. If there are other competing/compelling proposals, please let's talk about that and find a common solution we standardize. I personally do not think that "Sometimes waiting is a little better" is a valid argument.

If you have technical reasons as to why this work shall not proceed, please let us know, we want to deploy the best solution possible.

Thanks,
Max


On 11/20/19 9:33 AM, Stephen Farrell wrote:

On 19/11/2019 21:48, Eric Rescorla wrote:

But until we are prepared to do that, then defining the

protocol syntax doesn't really help that much.

+1



Sometimes waiting a bit is better:-)



S.
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]