On 07/31/2012 06:04 PM, Kristian Fiskerstrand wrote: > Currently we have a patch[0] ready that allows for these signatures to > be cleaned in the getting (and vindex) of the key,
A patch with the stated functionality would be a Good Thing.
> However, before creating a Pull Request into the SKS Trunk, we have to
> verify that this solution would not actually violating RFC4880.
If anything, the current sks implementation is violating RFC 4880, which
clearly states that transferable public key certificates contain:
- After each Subkey packet, one Signature packet, plus optionally a
revocation
SKS seems willing to record and produce more than one signature packet
in this position. The "one signature packet" is unambiguously intended
to refer to a subkey binding signature, fwiw, not any of the other
signature types.
Note that i think it's probably reasonable for sks to store more than
one subkey binding signature packet per subkey (to accomodate subkey
expiration revisions, particularly since sks has no cryptographic
verification in place, so it can't tell a valid subkey expiration
revision from an invalid one); i'm not arguing for blind adherence to
the spec, i'm arguing for practical utility here.
> Although
> there are implications that 0x10-0x13 signatures are for UID/UAT
> packages, and as such would not belong to a subkey, would starting to
> "hide information" be a violation of SKS's neutral way of storing data,
sks should not be so neutral as to store incomprehensible data (we
reject malformed packets, for example), and no one has stepped forward
with any explanation of why an identity certification signature could
make sense following a subkey.
Pursuing the patch to sks will fix one part of the problem here; gpg
probably also needs fixing to drop these bogus packets, or at least to
reassign them to their correct spot in the certificate if such a spot
can be found. Note also that the same signature packet might be
duplicated; if it fits in one place in the keyring, and a byte-for-byte
identical signature packet is found elsewhere, in a place where it is
not cryptographically valid, that latter copy of the packet can probably
be safely discarded.
my $0.02,
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
