Add recommendation about KeyPackage expiration

[TWal]

As discussed in #269, KeyPackages must expire to have post-compromise security. Otherwise, if a participant generates a KeyPackage, the attacker compromises the initialization key, and the KeyPackage is used to invite the participant later (say, a year later), the attacker will know the group's epoch secrets despite having compromised the KeyPackage a while ago.

There are hints about KeyPackage expiration in the document, but it is not mentioned explicitly in the section about KeyPackages, hence this PR.

[TWal]

Discussed above, Brendan mentioned that the mls-protocol RFC already talks about the importance of rotating KeyPackages for PCS:

New groups are also at risk of using previously compromised keys (as with post-compromise security) if a member is added to a new group via an old KeyPackage whose corresponding private key has been compromised. This risk can be mitigated by having clients regularly generate new KeyPackages and upload them to the Delivery Service. This way, the key material used to add a member to a new group is more likely to be fresh and less likely to be compromised

(although I don't agree with the term "new groups" here, it is "new" for the joiner but the group might be quite old for other participants. well, it's too late to change anyway)

Would it make sense to talk about it again in the mls-architecture RFC, because it roughly explains the consequences on the choice of maximum lifetime? Or it is not what the mls-architecture document is about?

[seanturner]

In WGLC, see this.