Re: [Secdispatch] Can Composite sigs move back to LAMPS?

[Stephen Farrell <[e-mail]>]

Hiya,

I'm guessing it'll be no surprise that I reckon that we
ought not adopt either piece of work at this time (sorry
for being so predictablel;-) I continue to think waiting
'till we know more is wiser.

I'd also note that CVE-2020-0601 may (when full details
emerge) provide very direct evidence that standardising
cryptographic parameter representations ahead of real
understanding of the algorithms and their implementations
and real uses can be a bad plan with implications that
only hit decades later.

Even if it turns out that (some years later) RFC5280 got
it right in saying "don't do that", I'd argue earlier
ASN.1 modules (whether from IETF, ITU-T, ANSI or whomever)
got it wrong in ever providing a way to encode custom
curve parameters.

Regards,
S.

On 16/01/2020 19:13, Mike Ounsworth wrote:
> Following up on in-room discussions at 106, and the ensuing list
> discussions, I'd like to ask for confirmation of the following
> points:
> 
> 1. There is enough interest in an obvious-and-straightforward
> implementation of composite signatures to continue working on it? 1a.
> The current draft for this is draft-ounsworth-pq-composite-sigs-02
> 
> 2. SecDispatch is assigning this back to LAMPS? 2a. The current draft
> might not be the most obvious-and-straightforward implementation;
> we're willing to simplify until it's in-scope for LAMPS.
> 
> --- Mike Ounsworth Software Security Architect, Entrust Datacard
> 
> _______________________________________________ Secdispatch mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/secdispatch
>