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? 

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.

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

---
Mike Ounsworth

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Roman Danyliw
Sent: March 10, 2021 4:32 PM
To: Benjamin Kaduk <kaduk@mit.edu>; Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
Cc: LAMPS <spasm@ietf.org>
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 <kaduk@mit.edu>
> Sent: Wednesday, March 10, 2021 9:54 AM
> To: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
> Cc: Roman Danyliw <rdd@cert.org>; LAMPS <spasm@ietf.org>
> 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/rbcufPA13VfSRLBw41Sbb5bO-J0/__;!!FJ-Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF8qb-IOM5GHb5nHQ5baDe_rQ$
[2] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/jxmWz7MxaShMEopwE-ZJfzsIbYY/__;!!FJ-Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF8qb-IOM5GHb5nHQ5xgZqFUg$ 

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF8qb-IOM5GHb5nHQ7jXlJoVg$ 