Issuer Fingerprint (was: Vanity Keys)

[Werner Koch]

[Moving discussion to gnupg-devel]

Or a new revision of the standard, I suppose. But I think that one or

A new key and signature packet version will take years to develop and
deploy. Thus I think it is better to first do something within the
standard which will be backward compatible.

We currently use this subpacket:

5.2.3.5. Issuer

(8-octet Key ID)

The OpenPGP Key ID of the key issuing the signature.

A new optional subpacket:

5.2.3.27. IssuerFingerprint

(N-octet Key Fingerprint)

The OpenPGP Fingerprint of the key issuing the signature. For
current versions of OpenPGP N has the value 20. Future versions of
OpenPGP may specify a different scheme for the fingerprint and thus
another value for N. Implementations should thus be prepared for
other fingerprint lengths but honor this subpacket only if N is 20.

could be used to overcome duplicate key id problems. The subpacket
type octet for that new subpacket would be 33. Note that

Adding a new Signature subpacket MUST be done through the IETF
CONSENSUS method, as described in [RFC2434].

which takes quite some time. Should be pursue this task or take a quick
solution by using notation data?

The size of a signature will increase by 22 or even more when using the
notation data approach. This is noticeable but given that we are anyway
moving to the smaller ECC algorithms I think this is acceptable.


Shalom-Salam,

Werner

[Hauke Laging]

Post by Werner Koch
A new key and signature packet version will take years to develop and
deploy.
Should be pursue this task or take a
quick solution by using notation data?

I suggest doing it right now because this work would not have to be done
for the next OpenPGP standard version any more. A notation-based
solution would not be part of the next standard.

Post by Werner Koch
The size of a signature will increase by 22 or even more

Who cares? Obviously not the average user who turns to 4096 bit keys
now... In case there are applications which need to avoid this a
configuration option might be introduced which avoids the additional
subpacket.


Hauke

[David Shaw]

Post by Werner Koch
[Moving discussion to gnupg-devel]

Or a new revision of the standard, I suppose. But I think that one or

A new key and signature packet version will take years to develop and
deploy. Thus I think it is better to first do something within the
standard which will be backward compatible.
5.2.3.5. Issuer
(8-octet Key ID)
The OpenPGP Key ID of the key issuing the signature.
5.2.3.27. IssuerFingerprint
(N-octet Key Fingerprint)
The OpenPGP Fingerprint of the key issuing the signature. For
current versions of OpenPGP N has the value 20. Future versions of
OpenPGP may specify a different scheme for the fingerprint and thus
another value for N. Implementations should thus be prepared for
other fingerprint lengths but honor this subpacket only if N is 20.
could be used to overcome duplicate key id problems. The subpacket
type octet for that new subpacket would be 33. Note that
Adding a new Signature subpacket MUST be done through the IETF
CONSENSUS method, as described in [RFC2434].
which takes quite some time. Should be pursue this task or take a quick
solution by using notation data?

My feeling is that whether we do a notation or an assigned subpacket, we do it via the IETF process. FWIW, adding an IETF namespace notation is via EXPERT REVIEW, which may be simpler than CONSENSUS. I lean somewhat towards a subpacket for several reasons (size, reusability), though.

I don't want to use a notation from the user namespace until we get to the "real" subpacket or notation, as we'll end up with both, ultimately, with some code using the user notation and some using the subpacket/IETF notation. We can end up stuck in that state for a long time, and have to support both for backwards compatibility reasons for even longer.

David

[Werner Koch]

Post by David Shaw
My feeling is that whether we do a notation or an assigned subpacket,
we do it via the IETF process. FWIW, adding an IETF namespace
notation is via EXPERT REVIEW, which may be simpler than CONSENSUS. I

However, it saves only a few bytes and has the same complexity as a user
space. We can keep this in mind as a fallback solution.

Post by David Shaw
ultimately, with some code using the user notation and some using the
subpacket/IETF notation. We can end up stuck in that state for a long
time, and have to support both for backwards compatibility reasons for
even longer.

Indeed this needs to be avoided. Checking with the PGP guys to see why
some of the subpacket types are marked as reserved and pick one of them
might also be possible.

I see the main problem that we have no WG and everything needs to go
through the indivual submission process. I have not seen any signs that
the WG will be re-established but this has never been offically
requested.

Move both discussions (WG establishment and IssuerFingerprint) to the
OpenPGP list?


Salam-Shalom,

Werner