Re: [lamps] Proposed recharter text

[Roman Danyliw <[e-mail]>]

Hi Mike!

> -----Original Message-----
> From: Mike Ounsworth <[e-mail]>
> Sent: Wednesday, March 10, 2021 6:03 PM
> To: Roman Danyliw <[e-mail]>; Benjamin Kaduk <[e-mail]>; Salz,
> Rich <rsalz=[e-mail]>
> Cc: LAMPS <[e-mail]>
> Subject: RE: [lamps] Proposed recharter text
> 
> Hi Roman,
> 
> That tightened scope works for me as it covers what I have already submitted
> (draft-ounsworth-pq-composite-sigs) as well as the drafts I'm currently working
> on a -00 of.
> 
> A couple nits:
> 
> 1. Worth a 5.b.0 about the format of public keys that can be used with the
> 5.b.1 and 5.b.2 mechanisms?

I can see that.  Others?  Perhaps that work is better framed with the current 5.a work which was (as currently written) about just identifiers (which we could expand to be formats too).

We will likely need to wordsmith all of the things in 5.x when we have it lined up side by side for consistency.

> One of the feedbacks I've received recently is to split composite public keys into
> its own draft and remove any keyUsage restrictions so that the composite
> public key format is separate from their usage in sigs, key exchange, public key
> encryption, etc (other than the restriction that a keyUsage applying to a
> composite key needs to apply to all component keys. No jamming a keyex and
> sig key into the same cert á la jumbo certs). This is currently in github here:
> 
> https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-
> keys/blob/master/draft-ounsworth-pq-composite-keys.txt
> 
> 
> 2.
> > using algorithm(s) vetted by the NIST PQ effort
> 
> Hybrid and dual mechanisms will likely be used for {RSA, PQ}, or {RSA, PQ1,
> PQ2}, or even {PQ1, PQ2}. In theory you could also do {RSA2048, RSA4096} or
> {RSA, ECC}, though I don't know why you would. Point is that they are not only
> for NIST PQ algs, but to combine traditional + PQ together.

Exactly. I was being sloppy trying to emphasize the "new" input (PQ algs) would be and what the specs would focus on.  All of those combinations involving PQ makes sense.  Restated:

5.b.1 = Specification(s) for identifiers, formats and operational practices to enable dual signature operations using traditional algorithm(s) and those vetted by the NIST PQ effort

> 
> 3.
> > How confident are we that draft-ounsworth-pq-composite-sigs is the starting
> point we want (for just 5.b.1)?
> 
> I am also curious about this :P

I leave it to be discuss in the WG.

Regards,
Roman

> ---
> Mike Ounsworth
> 
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Roman Danyliw
> Sent: March 10, 2021 4:32 PM
> To: Benjamin Kaduk <[e-mail]>; Salz, Rich
> <rsalz=[e-mail]>
> Cc: LAMPS <[e-mail]>
> Subject: [EXTERNAL] Re: [lamps] Proposed recharter text
> 
> 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!
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <[e-mail]>
> > Sent: Wednesday, March 10, 2021 9:54 AM
> > To: Salz, Rich <rsalz=[e-mail]>
> > Cc: Roman Danyliw <[e-mail]>; LAMPS <[e-mail]>
> > Subject: Re: [lamps] Proposed recharter text
> >
> > On Wed, Mar 10, 2021 at 02:26:36PM +0000, Salz, Rich wrote:
> > > I am concerned about having to decide the hybrid/multi-signature
> > > issue NOW
> > during the rechartering.  It's way too soon.  I think we need to
> > discuss the approaches in a technical context (i.e., as part of WG
> > discussions).  What's the best way to do that other than put vague words into
> a charter?
> >
> > I think we've seen (other) WG charters that include discussion of a
> > topic to decide on an approach, with need to recharter to actually
> > produce spec documents on that topic.  Just one option of many, of course...
> 
> +1.  We don't need to have approved charter language to discuss a topic.  We
> can even discuss and work on drafts that might shape the plan or approach.
> We just can't adopt them without a charter change.  I noted in an earlier email
> [2], we may actually find that as we decompose this problem, not all of it is
> appropriate to tackle in LAMPS.  Given some of the expressed uncertainty, we
> may also need to charter "this scope" (whatever it might be) in iterative
> "chunks".  Certainly, this creates some administrative overhead, but this
> shouldn't be too high.
> 
> In rereading the discussion and trying to answer my own questions [1] on what
> a tighter scope would be, let me test it with some replacement text:
> 
> OLD 5(b)
> The specifications developed will enable PKIX and S/MIME protocols to support
> hybrid key establishment and dual signature mechanisms
> 
> TIGHTER SCOPE:
> 5.b.1 = Specification(s) for identifiers, formats and operational practices to
> enable dual signature operations using algorithm(s) vetted by the NIST PQ
> effort
> 
> 5.b.2 = Specification(s) for identifiers, formats and operational practices to
> enable hybrid key establishment using the algorithms vetted by the NIST PQ
> effort and hybrid key establishment constructions defined in a revised SP 800-
> 56C
> 
> For me "operational practices" could potentially cover generation, validation,
> verification, etc.  As written, what it would exclude is updating PKI-related
> protocols and getting into any work that modifies other protocols that might
> leverage this work.
> 
> How confident are we that draft-ounsworth-pq-composite-sigs is the starting
> point we want (for just 5.b.1)?  Not pointing to this document specifically, but
> if we had one we could point to as a starting point this would also help create
> the bounding box on the new work and satisfy the other LAMPS constraint of
> "and there is at least one sufficiently well specified approach to the update so
> that the working group can sensibly evaluate whether to adopt a proposal"
> 
> Regards,
> Roman
> 
> [1]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/rbcu
> fPA13VfSRLBw41Sbb5bO-J0/__;!!FJ-
> Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF
> 8qb-IOM5GHb5nHQ5baDe_rQ$
> [2]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/jxm
> Wz7MxaShMEopwE-ZJfzsIbYY/__;!!FJ-
> Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF
> 8qb-IOM5GHb5nHQ5xgZqFUg$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!
> !FJ-
> Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF
> 8qb-IOM5GHb5nHQ7jXlJoVg$