> The lack of domain sep means stuff like a subkey itself is a valid payload signed by the master key Well. There are two proposals. If we go with the subkey

> The lack of domain sep means stuff like a subkey itself is a valid payload signed by the master key Well. There are two proposals. If we go with the subkey proposal, we'd not implement the simple protocol, solving that issue. > Signer is setup to have the whole input in memory at once It's fine. > This text says very little about validating trusted keys. A signature where you just take the pubkey from the input That would be silly. APT would maintain a list of allowed public primary keys. The spec hints at that with "Clients shall verify all signatures from supported algorithms in the Release file, whether a given key is considered trusted or not." > No obvious affordance for additional signed metadata, which is useful for forensics. So, for example, if a project has multiple parties with access to the keys they may want to tag which user(s) authorized the signature or included a timestamp. If their signing is performed by a HSM (e.g. something like USB armory that allows no user access) the consistency of their metadata could be preserved. This could probably be kludged on by requiring the metadata just be inside the payload somewhere. We don't have a use for that. The feature set of GPG is already over the top. > It's not entirely clear to me that it's supported to hand out multiple subkeys to different parties all with the same serial, and they stay all equally valid until a key is observed with a newer serial (at which point all subkeys need to be updated) Yeah, the serial exists to revoke all priorily issued subkeys, effectively.