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 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp