On Sat, Aug 25, 2001 at 10:46:14AM -0400, Michael Young wrote:
Florian Weimer wrote:
This should probably go into a separate RFC. Currently, RFC 2440 and
RFC 2440bis deal only with syntactic issues
and Jon Callas wrote (this and subsequent quotes):
This is my point: I don't see an obvious best answer. Furthermore, 2440 is
a data specification standard, not a user interface guide or software
I understand that the specification primarily covers syntax, but
if it doesn't cover at least some interpretation issues, then
interoperation is seriously hampered. Who cares how the bits
are ordered if a sender and receiver interpret wildly different things?
We need to have a meeting of the minds on more than just formatting.
Secondarily, one way I look at it is as a receiver. I fetch a key from a
server and it has multiple primaries. How do I resolve this? Yeah, there's
On this specific issue, I want to know what a *sender* must do
to change its "primary" marking such that a receiver will
understand. The same applies to any material in the self-signature,
and this need may arise several times over a key/userId lifetime.
The draft does specify have a way to do this - rewriting the
signature(s) in place ("Since a self-signatures contain important
information about the key's use, an implementation SHOULD allow the
user to rewrite the self-signature..."). Both PGP and GnuPG do this.
The problem arises later, when the key with the new self-signatures is
added to a keyserver or sent to someone else who already has the key.
Most current implementations in the field will merge their existing
copy with the new one, resulting in two self-signatures. It could be
argued that they should not do this, but since it's going to happen,
we should at least make a provision for it.
Like you, I favor a "most recent prevails" recommendation. I think
that revoking and re-making self-signatures is going to result in some
massive keys if every time someone changes their preferences it means
a new revocation packet and self-signature.
I don't think that this is just a syntax issue, and therefore
inappropriate for 2440bis. 2440bis makes a point of covering syntax
issues that relate to security. Since the information in a
self-signature can affect the security of messages sent to the key,
I'd say this is an appropriate issue to address in 2440bis.
"Most recent prevails" makes a lot of sense. It can even be a SHOULD,
like the sample wording I sent out a couple of days ago, rather than a
MUST. In fact, SHOULD describes it nicely (e.g. "We recommend you do
it this way, but you can do it any way you like if you think about the
implications first.").
last, unless of course it's in the future. Perhaps an even better answer is
to have the implementation ask the user which one to use.
That's always an option, regardless what the specification suggests.
But, I don't want to *force* user interface pop-ups (or even receiver
policy decisions) when the creator has clear intentions.
Yes.
David
--
David Shaw | Technical Lead
<dshaw(_at_)akamai(_dot_)com> | Enterprise Content Delivery
617-250-3028 | Akamai Technologies