Re: [lamps] Potential Topics for LAMPS Recharter

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Apr 2, 2018 at 10:34 AM, Stephen Farrell <[e-mail]>
wrote:

>
>
> On 30/03/18 19:05, Russ Housley wrote:
> > 2) draft-housley-cms-mts-hash-sig: SECDISPATCH suggested that the
> > LAMPS WG take on hash-based signatures for CMS as an additional work
> > item.
>
> As I said at the mic in London, I support this work being done
> in the IETF, but I'm not sure LAMPS is a good choice. It's not
> a *terrible* choice, but doing this in LAMPS is a bit odd as I
> for one would argue that an experimental RFC could be the right
> target for this work and that seems like a mismatch with the
> LAMPS charter.
>
> Re-chartering LAMPS to allow for this kind of work also seems
> to me to risk hitting the PKIX problem where we end up with a
> WG that's a catch-all for anything related to PKI. I figure
> that'd be a bad plan, but others may disagree.
>
> In summary, I think maybe SUIT is a better match for hash-based
> sig work, given that s/w signing is the likely use-case for
> these schemes. That said, I'm not subscribed to SUIT so don't
> know if there's real interest from participants there either.
> I'd also be fine if the ADs spun up a new short-lived WG just
> for this work.
>
> FWIW, if the end result here is to do this work in LAMPS, I
> won't whine about that. (I may whine if this WG really starts
> turning into PKIX++ though:-)
>

​I agree that PKIX became a problem. But a large part of the problem was
that PKIX became a brand in the industry and so implementing 'all of' PKIX
became an issue.

I don't see SUIT as a good fit. First, I don't think we are ready to use
these sigs for software signing, I think we would be using them for
authenticating roots of trust to be used in extremis. To go beyond that
narrow remit openeth up a very large problem space. We would have to go
through the whole issue of how to bootstrap QR crypto applications.

I do not think we need to go any further at this stage than to convince
ourselves that we tell people to create sufficient signing capacity to
support the ability to bootstrap.

The way I would like to containerize the problem is:

LAMPS: Itsy bitsy extension to certificate signing certs to embed QR
signature bootstrap
IRTF: Propose QRKI (Quantum Resistant Key Infrastructure) and bootstrap (a
five year mission)