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

["Kampanakis, Panos" <[e-mail]>]

Hi Serge, 

> So now the key owner (or certificate issuer) can limit a composite key's use to a particular algorithm, or leave it open. 

Why would the key owner want to do that? The key owner has two keys and can sign with two algorithms which he trusts, otherwise he better not use them. So, it can't be because the key owner wants to convey one of its keys are not secure. 

If it is as a migration mechanism, then how would the key owner or CA know if all the verifiers have been upgraded to switch to AND from OR? if someone wanted to use composites as a migration mechanism, they could just implement the verifier to verify with OR. And I have to say, that in decades of PKI and some migrations, this idea has not come forward, so I highly doubt anyone really needs it. 

> Someone who is starting to lose trust in RSA but also doesn't quite trust the PQ algorithm would choose 3.  The CA would be asserting that verifying just one of the component signatures is not enough to ascertain that the signature is associated with the identity named in the certificate.

How can the CA do that? Today the CA signs an identity and public key, it does not decide if the public key is secure enough. Now we are asking the CA to make a decision about what is secure or not, which is significantly different from what it does today. Not to mention that the CA should not make decisions about what algorithms the peers should or should not trust.

Personally, I think it is better if all verifiers do plain old AND and this draft does not define any logic. Some verifiers could chose to verify with OR or K-of-N etc for migrations or other reasons.
 



-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Serge Mister
Sent: Saturday, April 23, 2022 10:15 AM
To: Kampanakis, Panos <kpanos=[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: RE: [EXTERNAL][lamps] PQ-composite OR or K-of-N logic

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Hi Panos,

Suppose we have a signature algorithm with parameters:

  - id-composite-signature
  - params specifying either AND (the verifier must verify all component signatures), or Any (the verifier must verify at least one component signature)

and also a generic id-composite-key OID that (just) identifies a composite key

In SubjectPublicKeyInfo, one could specify:

  1. id-composite-key - This would allow use of the key pair with any signature scheme compatible with composite keys

  2. id-composite-signature (without parameters)  - This would allow use of the key pair with this signature algorithm only, in either AND or Any mode

  3. id-composite-signature with params AND - This would allow use of the key pair only with this signature algorithm in AND mode

  4. id-composite-signature with params Any - This would allow use of the key pair only with this signature algorithm in Any mode (not sure why one would choose this option - if Any is ok, AND is ok too)

So now the key owner (or certificate issuer) can limit a composite key's use to a particular algorithm, or leave it open.  Does that help?

I'm thinking that someone using composite for compatibility would choose option 1 or maybe 2.

Someone who is starting to lose trust in RSA but also doesn't quite trust the PQ algorithm would choose 3.  The CA would be asserting that verifying just one of the component signatures is not enough to ascertain that the signature is associated with the identity named in the certificate.


Serge

-----Original Message-----
From: Kampanakis, Panos <kpanos=[e-mail]>
Sent: Friday, April 22, 2022 11:12 PM
To: Serge Mister <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: [EXTERNAL] RE: 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.

______________________________________________________________________
Hi Serge,

>   - 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).

I am not following how that ties to the OR logic. Are you suggesting that a signer has two public keys (which will go in its cert) and the corresponding public key OID will say "sign with one key but the other one does not matter" (something like OR logic)? If the signer has two keypairs he better trust both algorithms to sign with.

Panos


-----Original Message-----
From: Serge Mister <Serge.Mister=[e-mail]>
Sent: Friday, April 22, 2022 2:24 PM
To: Russ Housley <[e-mail]>; Kampanakis, Panos <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: [UNVERIFIED SENDER] RE: [EXTERNAL] Re: [lamps] 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 <[e-mail]> On Behalf Of Russ Housley
Sent: Friday, April 22, 2022 12:41 PM
To: Kampanakis, Panos <kpanos=[e-mail]>
Cc: LAMPS <[e-mail]>
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=[e-mail]> 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
[e-mail]
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.

_______________________________________________
Spasm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spasm