Re: [openpgp] Algorithm expiration

Hiya,

On 02/06/2022 11:30, Aron Wussler wrote:
> Hi Stephen,
>
> > I have to say (as a co-chair), that I could see it surfacing quite
> > a number of IETF process issues if we adopted it now.
>
> My original idea applied actually to the PQ composite algorithms,
> since they are meant to be a temporary patch until we know more about
> PQC and if the algorithms are safe as standalone. While reporting
> back the workshop results there seemed to be an interest into
> including this into the crypto refresh, as binding this to v5 would
> give the advantage of "if you want to use v5 then you have to
> implement expiration". This would not allow for some implementations
> to ignore it, and therefore making it a useless standard, by being
> compatible with v5 but not with expiration.
>
> With this I'm just trying to point out the advantages of binding
> expiration to v5, and not trying to delay the refresh forever.
I'm entirely sure of that! Sorry if I gave a different
impression;-) I'd just be quite worried about timing if
the WG tried to get this done now. Considering it for later
does seem to me like a fine discussion to have and a good
output from that meeting.

Cheers,
S.

> I am
> not opposed to making this a separate RFC, try to standardise this at
> the CFRG or IETF level, or introduce it with the PQC RFC.
>
> Cheers, Aron
>
> -- Aron Wussler Sent with ProtonMail, GPG key 0x7E6761563EFE3930
>
>
> ------- Original Message ------- On Thursday, June 2nd, 2022 at
> 12:03, Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
>
>
> > Hiya,
> > On 02/06/2022 09:03, Aron Wussler wrote:
> > > Hi All, At the summit we discussed as an action item to propose
> > > an expiration for algorithms, to allow easier planned
> > > deprecation. I've prepared an MR to the refresh, that drafts a
> > > proposal for this. I've added an expiration column for all
> > > public, symmetric, and hash algorithms and defined the behaviours
> > > for expired algorithms.
> > > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/197
> >
> > That's an interesting idea, but I have to say (as a co-chair), that
> > I could see it surfacing quite a number of IETF process issues if
> > we adopted it now.
> > For example, I don't believe any IETF RFC has been issued with such
> > "best before" dates in the past, so this'd be a process-innovation
> > that might well attract quite the discussion, not to mention the 
> > potential for debate as what value to use for each specific alg,
> > and whether or not such dates should be protocol-specific or apply
> > to all IETF standards track RFCs. So, (again as co-chair,), I'd
> > want to be pretty confident the WG are keen on this before I'd be
> > happy we had consensus to go for this now. (Because it could delay
> > the currently chartered work a lot, not because I do/don't like the
> > idea.)
> > OTOH, if/when we get the refresh work completed, then this seems
> > like a fine topic to consider if folks do want to re-charter to
> > take on more work in this WG (or maybe even form a WG for only this
> > idea, who knows?).
> > Cheers, S.
> > > Cheers,Aron
> > > -- Aron Wussler Sent with ProtonMail, GPG key 0x7E6761563EFE3930
> > > _______________________________________________ openpgp mailing
> > > list openpgp(_at_)ietf(_dot_)org
> > > https://www.ietf.org/mailman/listinfo/openpgp
> > _______________________________________________ openpgp mailing
> > list openpgp(_at_)ietf(_dot_)org 
> > https://www.ietf.org/mailman/listinfo/openpgp

OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp