On Fri 2019-08-30 09:28:49 +0200, Werner Koch wrote:
On Fri, 30 Aug 2019 01:15, dkg(_at_)fifthhorseman(_dot_)net said:
If there's a broader consensus on the list that we shouldn't explicitly
associate no-modify with a 1PA3PC mechanism, then i can drop that part
I can't yet decide on this because I have no clear vision on how to
implement the workflow to create the new attestation. Probably they
should be handled like a local signature and only exported when needed.
Older versions need to be dropped to avoid cluttering the keyblock with
lots of old and useless attestations.
I agree that any OpenPGP keystore (local keyring, keyserver, whatever)
should be able to legitimately discard all superseded Attestation Key
Signatures, keeping only the most recent one. I think this is true
regardless of whether we explicitly tie keyserver-prefs no-modify to
this mechanism.
[ Digging into the weird corner cases: there is a question about what
to do when one receives an Attestation Key Signature with a
Signature Creation Time that is in the future. I think it is
acceptable to drop/discard these objects (perhaps with some window
of allowance for possible clock skew) ]
If you're generally ok with the protocol mechanism for attestations
proposed here, i'd be happy to share my notes for what i think a initial
interface for managing attestations with GnuPG might look like -- i can
do that on https://dev.gnupg.org/, or on gnupg-devel(_at_)gnupg(_dot_)org,
wherever
you prefer.
All the best,
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp