ietf-openpgp
[Top] [All Lists]

Re: 11.2 Dual KeyIDs for RSA keys?

1998-04-17 21:28:32
Jon Callas wrote:
Within the openPGP framework, a keyid is a 64 bit number, and you can use
them at will.

tzeruch wrote:
Which is fine when there is a one-to-one mapping.  What I am pointing out
is technically a keyid is either of two possible 64 bit numbers.

It's a perfectly fine feature to have V3 => V4 migration, but I'd consider
the V4 key to be a completely separate key, and forget that it shares bits
with the V3 one.

I see nothing in the formats document that would contradict this.  I
also see nothing that would preclude the possibility of an
implementation keeping track of both the V3 and V4 Key ID and
fingerprints of the key and taking appropriate action if either of them
is seen.  I think it would be unlikely to achieve the desired effect
across the range of PGP-like programs if you were to do V3 sigs with
your V4 key or vice versa, but I feel it's not the place of the formats
document to preclude this usage.

But then there is a problem.  If I already have a V3 RSA key, and want to
use the V4 features, I will have to convert the key.  Considering it as a
new key might work, but if I want to sign something to a V3 recipient, I
have to use the old ID along with the format (i.e. keyservers won't have
the key under the old ID).

Or are you saying I MUST not generate any V3 signatures with V4 RSA keys?

Could you achieve the desired effect by sending both the V3 and V4
versions of your RSA key to the keyservers?

Adding these MUST options is reasonable, but then they should be added to
the spec.  Letting implementations use RSA keys in both V3 and V4 contexts
on the fly is also reasonable.  But something should appear in the spec
saying what should be done - Do I check both possible keyids on a V4 RSA
signature or just the V4 type?  Am I allowed to export my V4 RSA key in V3
format?

I think this is an implementation and program behavior detail, and thus
should not be in the formats document.  However, I approve of and applaud
your approach of being willing to accept many different combinations and
permutations of formats.

        Jim Gillogly

<Prev in Thread] Current Thread [Next in Thread>