Hi Paul,
* Paul Hoffman <[EMAIL PROTECTED]> [2007-06-20 02:50]:
>
> At 1:43 AM +0200 6/20/07, A. Pagaltzis wrote:
> >* Paul Hoffman <[EMAIL PROTECTED]> [2007-06-19 21:40]:
> >> The method for a server to indicate to a third party whether
> >> or not the client signed an Entry Document is by including
> >> the client's signature in the published entry, even though
> >> that signature is likely to be invalid.
>
> >Encouraging servers
>
> Stop right there. Nothing in the quoted text *encourages*
> anyone. We said that there was a method, which is completely
> true.
No, it is entirely false, because cryptographically, a consumer
has no way whatsoever to know whether the signature was
originally valid and where that once supposedly valid signature
originally came from.
A consumer cannot assume *anything* about an entry with an
invalid signature other than that it is an entry with an invalid
signature.
> We also said that this is "the" method, which is also
> completely true (we didn't create another method).
This is false, by extension from the previous sentence being
false; and so we didn’t create any method for this at all, which
makes this claim doubly false.
> That is a far cry from encouragement.
I don’t understand how this first sentence doesn’t stand in
complete contradiction with the previous ones. Sure, servers
might not desire to signal to consumers that the entry was signed
by the client, in which case the paragraph in your proposed spec
text would not act as encouragement. But for those servers who
wish to do so, you are practically telling them to publish the
invalid signature.
Sure it doesn’t encourage all servers, but that seems like hair-
splitting. It does encourage a subset of servers, and more
importantly, the most significant subset of servers as far as
this issue is concerned. If you need me to thusly qualify my
claim that we’d be encouraging servers to publish invalid
signatures, that’s fine with me, but that’s still what we’d be
doing.
> Given that this is the Security Considerations section, we
> should have a security reason for the nudge. I don't think we
> have one. There is no security problem with publishing a
> known-bad signature.
Not a first-order effect, no. Certainly a second-order one,
though; no one is served by a situation where consumers can’t
unconditionally reject entries with broken signatures. Except
the bad guys, anyway.
> If the WG wants to make a strong encouragement here, that's
> fine, but we do so against our earlier trend.
If you want me to tone down the language and avoid
encouragements, I guess that’s fine. Just as well to spell out
the rationale and leave the conclusion to implementors:
A server is allowed to strip client-applied signatures, to
strip client-applied signatures and then re-sign with its own
public key, and to oversign an entry with its own public key.
The meaning to a third party of a signature applied by a
server is the same as a signature from anyone, as described
in [RFC4287]. Third parties may choose to unconditionally
reject entries with invalid signatures as they cannot
possibly make any assumption about the origin of such a
signature and its validity at any previous point in time.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
