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

["Klaußner, Jan" <[e-mail]>]

Hello all,

my impression is that we have different us cases in mind. For a simple
authentication having the policy on the relying side is enough.

When looking at the key usage for contenCommitment /nonRepudiation it is
important for the signer to define under which conditions it can be hold
responsible for its signature.
This affects in my opinion
* how the signature shall be verified
and in case we sign a public key
* how the key shall be used - for composite keys also how the signature
generation and verification is defined
Failing to do so can lead to fines e.g. for a CA in case the key is misused.

Therefore I am still convinced that the composition algorithm needs to be
defined and even bound to the key.

Best regards
Jan

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[e-mail]> Im Auftrag von Russ Housley
> Gesendet: Freitag, 22. April 2022 20:30
> An: Serge Mister <[e-mail]>
> Cc: LAMPS <[e-mail]>; Kampanakis, Panos
> <kpanos=[e-mail]>
> Betreff: Re: [lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic
> 
> Serge:
> 
> RFC 4055 provides a way for an RSA public key to be used with RSA-PSS or
> with any flavor of RSA.  It is good crypto hygiene to not use the same key
> with many different algorithms.  However, at the time that RFC 4055 was
> written, no one could find an attack if the same RSA private key was used
> with RSA-PSS, RSA-OAEP, and PKCS#1 v1.5.
> 
> To me that is quite different situation than K of N, AND, OR, and ANY
being
> discussed here.
> 
> Russ
> 
> > On Apr 22, 2022, at 2:23 PM, Serge Mister <[e-mail]>
> wrote:
> >
> > 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