Re: [lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic

Hello all,

As I mentioned on the call, I'm not fully convinced that deciding which signatures a relying party must verify is entirely a decision for the relying party.  When an entity obtains a certificate from a CA, signatures verifiable with the certificate are attributed to the entity named in the certificate.  The certificate holder then wouldn't want a weak key bound to their identity.  If a composite key can be used in "OR" mode, the key is weakened when any of the algorithms is weakened.

This view is supported I think by RFC 4055 section 1.2 which states that the rsaEncryption OID implies that "the RSA private key owner does not wish to limit the use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP" and also "When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object identifier MUST be used in the algorithm field within the subject public key information".

Applying this idea to composite, and in line with the idea that it is the signature algorithm that should dictate whether signing and verification require all or only some of the component signatures to be generated/verified, I'm picturing that we could have:

  - An OID that identifies a composite public key, that is agnostic to how those keys are used (similar to rsaEncryption)
  - OIDs that identify specific signature algorithms, possibly with parameters, that could be specified in SubjectPublicKeyInfo and would then limit use of the composite key to that signature algorithm (and specified parameters, if they are specified).

The latter OIDs would also be used in SignatureAlgorithm fields.

Serge

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Friday, April 22, 2022 12:41 PM
To: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>
Cc: LAMPS <spasm@ietf.org>
Subject: [EXTERNAL] Re: [lamps] PQ-composite OR or K-of-N logic

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

______________________________________________________________________
(No hats)

On the call, many people expressed concern that the approach in the I-D tries to bind the signature verification policy to a public key.  These people prefer an approach where the relying party applies their own policy.  I tend to agree that the verifier should determine the policy.

Russ

> On Apr 21, 2022, at 11:00 PM, Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org> wrote:
>
> Hi all,
>
> This was discussed in the interim meeting yesterday, but I promised to also bring it up to the list.
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/__;!!FJ-Y8qCqXTj2!ffo5wF8YG-Y6-Yy18R5u7wBsVKkWkyeR7qUlRxq7XBZvfx0AboetFja4fsrL-voFL9twTLwMovXZX-7WEwPpKF88kw$  includes a Composite-OR and a Composite-OR-Legacy mode. And Mike also mentioned K-of-N logic in the meeting. These allow for the signer to define the verification logic of the composite signature. As many pointed out in the interim meeting yesterday, it is counter intuitive for the signer to tell the verifier what to verify. If the verifier does not trust one of the signatures in the composite signature it can make a decision on what to do based on its policy. It could fail unless all sigs verify or do something else.
>
> Adding granularity in the signature to tell the signer what to do not only changes what we know and use today, but it also opens cans of worms with complexity and mistakes that could happen in implementations.
>
> I suggest to just define one mode. That is a composite sig is two signatures of the same thing with two algorithms using two keys. The signer is supposed to verify the composite signature. How it does that is beyond this draft.
>
> Rgs,
> Panos

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ffo5wF8YG-Y6-Yy18R5u7wBsVKkWkyeR7qUlRxq7XBZvfx0AboetFja4fsrL-voFL9twTLwMovXZX-7WEwMko2CdcA$
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.