Re: [lamps] Call for adoption for the composite-related Internet-Drafts

["Dr. Pala" <[e-mail]>]

Dear Michael, All,

thank you for your reply - I would like to follow up with your reasoning for not supporting adoption.
Specifically, you wrote:

/> I have not been able to accept the rationale(s) behind the idea of 
imposing significant (short-term?)////> engineering changes like these on reliant applications in the absence 
of any clear understanding of////> the impact of A) revocation of classical key components and B) 
deprecation of classical algorithms.////> Those problems, treated as "out of scope" in these documents, is 
truly the crux of the matter. Do we/

I agree with you that there are two different connected issues here. The issue of reducing the risk
connected with the use of the individual algorithms, and how we are going to address algorithm
deprecation.

For the first issue, I am not sure about "imposing" any significant burden on anybody. Exactly as you
might not support the use of a specific algorithm in your ecosystem, you might not support the Composite
or Explicit Composite ones. However, should you want to be able to combine algorithms, Composite provides
the possibility to do that at the crypto library level, instead of having to modify the application
layer. Composite is meant to be an opportunity and a tool that can be used when you need it.

As an example, in our infrastructure we only support RSA and SHA256 and we do not support ECDSA.

For the second issue, dealing with algorithmic revocation/deprecation, we did present on the topic and
was REQUESTED BY THE WG to be removed from the draft and to put it in a different document.
As usual, we followed instructions and we did remove it from the main document. We are putting together
a different I-D for handling algorithmic revocation/deprecation - I am looking for collaborators,
are you interested in joining? The proposed solution was to leverage extensions in CRLs and OCSPs - the
combination with multi-algorithmic support (either vertically or horizontally) provides a possible
easy solution that can be adopted across entire ecosystems (deterministic behavior).
///> go to the trouble of supporting this nonsense when it will all have 
to be abandoned as we approach////> the apocalypse? This DOES NOT make the migration easier... it 
introduces completely unnecessary structures////> that are likely to have a severe negative impact on interoperability./

I am not sure I share the same view as "it will all have to be abandoned...". Indeed, I find this option
to be a very appealing option for PKIs moving forward, allowing to spread the risk across different algorithms
in the future - migrating from different versions of the same algorithms (e.g., adjusting security parameters)
or migrating across different algorithms (e.g., from a PQ to another PQ). The choice to use an explicit
set of combinations was requested by the WG for adoption and we included it. Moving forward, adding new
OID combinations in the table will provide the possibility to extend the current version of the proposal.

Also, please, do not use terminology like "nonsense" - although you might not support the idea, the use of
such terminology is not useful in an engineering setup. We welcome all possible contributions and feedback,
however, please, let's just all be respectful of other people's work.


/> In particular, I take exception to the claim that: > > "Migration: 
During the transition period, systems will require mechanisms that allow 
for staged migrations////> from fully traditional to fully post-quantum-aware cryptography." > > 
Did we vote on that?/


When you say "Did we vote on that?" what do you mean? The paragraph is just an example for a possible utilization
of Composite: allowing combining traditional and post-quantum algorithms to spread the risk of early adoption
while still allowing quantum-resistance to be deployed early (i.e., instead of just one algorithm failure you
need two).

Another use-case that Composite enables is for allowing devices that cannot be upgraded to use post-quantum
algorithms to still participate in the network and rely on the traditional algorithms, even when you are already
deploying quantum-safe solutions (e.g., as a tool for backward-compatibility rather than risk management).

Specifically, if you support the K-of-N option, then, if your risk profile is acceptable for your environment,
you can still validate part of the signature instead of having to replace the hardware right away - from that
point of view it provides a tool that you can leverage during migration.

I hope I did address some of your concerns and maybe that can change your opinion - adopting the drafts
to make them better :D

Also, please, let me know if you'd like to collaborate on the Algorithm Deprecation I-D, I am looking for
collaborators on that!

Kind Regards,
Max

-- 

Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo