Comments from Call for Adoption

I think I actually agree with Tim that there is a problem here that needs to be solved, but it’s not clear exactly what that problem is. For example, the current composite drafts allow for a wide range of things: • Composite CAs. • Composite EEs from composite CAs. • Composite EEs from non-composite CAs. • CompositeSignatures from two unrelated certificates or crypto modules. • For TLS? For S/MIME? For custom CMS applications? For CRL / OCSP? For code-signing? For eIDAS? • How does this interact with CMS multiple SignerInfos?

I’m coming around that Tim was right to point to the long string of MAYs in section 3.1 of -sigs 3.1 as an indication that the underlying problem is too broad and il-defined.

Tim also points out that the core idea is simple, but complexity creeps in around the corners, for example: • How do you lift from an existing RSA PKI to a composite PKI? That seems like a hard breaking flag-day, especially since we’ve banned re-using component keys between single-alg and composite. • How do you lift from a composite PKI to a single-alg PQ PKI? That seems like another hard breaking flag-day. • The business of needing to check that the inner AlgIDs match what you expected for this composite. • The business of making it really tricky for a CA to tell if a component key was part of another composite key that was declared compromised.

I’m coming around to the point that it’s hard to tell what’s necessary complexity when the problem statement is il-defined and does not have group consensus.

I think Tim and Rich’s objections, if you take a big step back, is that this proposal contains documented landmines and a few hackathons is fine, but until we try deploying this at scale, we won’t know which of those landmines blow up into operational nightmares and which don’t.

These comments seem to indicate we need to clearly define use-cases. Sure, we can do that. We can ask BSI and others to share their use-cases with us. I know we are planning to support them at Entrust for all our various PKI use-cases.

Inability of author to identify an application which makes sense
If there were a tight applicability statement as to when these mechanism are and are not useful/usable then that could help.
There still need to be some serious conversations about exactly what we are trying to achieve, and exactly how it is supposed to work.

This seems to require additional statements on revocation and algorithm deprecation. We had done that in the past but were told to “not go there” so we didn’t. I think a couple of lines of text or section could handle these arguments. Revocation and algorithm deprecation. Serge brought up relevant use-case yesterday when I talked to him at work. What happens if openSSL decides to pull support for RSA in their library because a PQC breaks it, but composite still relies on RSA? Obviously refactoring is required

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.

A couple technical musings but is there something concrete here that we can action?

Signatures have limited validity periods, but duration of confidentiality is unlimited.
Data formats seems to have a generic composition leading to excessive complexity. Requires a total redesign.
Combining signatures and public keys is a bad idea
Creates new failure modes for systems.

Perhaps we didn’t do a good enough job of presenting composites as fully distinct signatures from the individual algorithm primitives which make up the signatures. We could change the posture of the draft…

That's still breaking an invariant that has applied in PKI protocol and code design for >30 years: that there is a 1:1 mapping between signatures and key pairs and between cert spki values and key pairs.
For signers it's highly likely there's an assumption that one private key can be protected with one password - changing from 1:1 to something else there is liable to be hard or generate problems.

This is an implementation concern. We have at least 6+ implementations and it works. We could tighten up all the edge cases.

even if one has only one blob of octets in an x.509 certificate, that will have to map to two function calls for signing or verifying, one specific to each algorithm, and that bit of code will likely break internal service provider interface (SPI) models between the PKI code and underlying crypto alg implementations - you'd maybe end up with a single SPI call that internally makes two SPI calls, and who knows what that'd break, given all the variability in term of how implementations of the same algorithm differ (e.g. h/w, s/w, etc.) and how things like the set of preferred or disallowed algorithms are passed into libraries as strings that control how those SPIs can be used.

I guess we could add a note about TLS?

would these drafts claim to be relevant for TLS or not? The drafts say yes. One of the draft authors said no. Given TLS is the most important security protocol today, that lack of clarity seems to me fatal for a draft adoption discussion.

I am sure we could have got Carl Wallace and a number of others to say they supported it as well (Carl sent us a separate email saying he was surprised it didn’t go through). I don’t think it would have made a difference. From what I read in 7282, a single person could make an objection, and if that is not sufficiently addressed, then the chairs could still say there was not consensus.

Updated Chart:

EntrustCorporation / draft-ounsworth-composite-sigs

Comments from Call for Adoption #108