ietf-openpgp
[Top] [All Lists]

Re: section 4.3

1997-12-30 11:14:16
William H. Geiger III, <whgiii(_at_)invweb(_dot_)net>, writes:
I have a question regarding the Packet Tags (aka Cipher Type Byte) in
section 4.3 [page 16].

It has 14 as subkey packet, 15 reserved, and 16 as comment packet but
accorinding to my notes the comment packet currently is 1110 (14 base 10).
Also since 0-F is 0-15 (16 digits) it would seem that the Reserved status
for type 15 needs to be removed and that the Subkey Packet type be
assigned this number. This is assuming we are keeping current CTB's as is
and reserving the 2 byte type codes for future use.

We changed packet type 14 from comment to subkey intentionally, to
facilitate backwards compatibility with PGP 2.6.2.  Packet 14 had never
actually been emitted by any version of PGP, but it would be ignored.
This way subkey packets don't break PGP 2.6.2.  The DSS/ElGamal keys
don't work with that version, of course, but at least 2.6.2 doesn't crash
if it sees one.  This was better than other solutions we tried.

There are quite a few issues that AFAIK are still unresolved yet there
seems to be little to no discussion of them:

- -- UserID Revocation
- -- Signing of Just the Key
- -- Signing of Key and multiple userID's

These would be better left for V2 of OPGP.  I continue to believe that our
best approach is to avoid introducing more new features.

I also have some problems with some of the signature subpackets.

- -- Revokable

Is it really appropriate to have a signature that can not be revoked?

This was intended to be used along with the third-party revocation
mechanism.  This allows you to specify that some third party key has
the power to revoked your key.  People are constantly forgetting their
passphrases and are unable to revoke their own keys.  This will allow
them to request a revocation from a designated third party.

However if this third-party authorization self-signature were itself
revocable, then someone who stole the secret key could revoke the
third-party revocation authorization, making any attempt by the third
party to revoke the key be ineffective.  So at least in this case it
makes sense for the third party revocation authorization self signature
to be irrevocable.  Given one use, more may be discovered, so I thought
it should be a separate subpacket.

Also I didn't note any mechanism to inform an end user that various
preferences in the subpacket had changed. Perhaps there could be an
"update" signature subpacket. Basicly this is how it would work:

An interesting idea for a future version.  We need to think about
extending it to go beyond a binary flag, though, since multiple updates
may occur at different times.  Also, I suspect that we may eventually
have multiple self signature preference packets and you'd have to specify
which one(s) had been updated.

Hal

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