From: Brad Templeton (brad@templetons.com)
Date: Thu May 04 2000 - 15:22:10 CDT
Signing just the headers within multiparts creates a requirement
that signature checking software parse article bodies. I think they
should be just an array of bits. Sign the body if there is a body, but
just as an array of bits.
> There is also provision for Verified headers which may be added by
> agents that have checked a Signed header. Verified headers may
> themselves be included in further Signed headers; this may be
> especially useful in the case of gateways which find it necessary to
> change an article in ways that invalidate an original signature.
If you invalidate a signature you might as well remove it, it serves
no purpose. While it is possible to leave a signed flag that says
"this used to have a signature and it was OK to me" that is very poor
"weak link" security.
It also begs the question of whether such a gateway passes on both signed
and unsigned articles. Some have even made the astounding suggestion
gateways would pass on articles that are signed but fail the signature
test -- ie. forgeries and mistakes. You can't reconcile this easily.
If a gateway signs an article, it should be inherent that it had reason
to trust what it signed, or I should not trust it. If it is a gateway
from an uncontrolled zone, what value is there in having it sign things
if anybody can inject anything and get it signed? Indeed, this can be
of negative value by generating false trust.
> header-parameter
> = attribute "=" value
We should not define header parameters in the syntax of our
headers. Every header should use exactly the same syntax for its
modified parameters, the same one all MIME headers use. There should
not even be the suggestion that more than one parser is required.
Canonicalization.
As has been said before by several here, you want as simple
a canonicalization algorithm as possible. The idea of complex
mapping of comments etc. is sure to lead to trouble.
We can get away with a simple canonicalization because it is
inherently enforced. Any attempt to modify the headers against
the simple rules fails. The articles will not be propagated.
People won't code bad transformations because they simply won't
work at all, once downstreams are checking signatures.
There are a few canonicalizations we can't avoid, but we should
limit ourselves to them, and only them. They are the addition
of other headers and the re-ordering of headers. Some would
argue for the re-folding of headers but actually I'm not sure
we even need to support that -- why should relays or injectors
need to re-fold headers?
Rewriting of headers doesn't work with signatures, it's wrong to
even make it try. Since all programs that sign their headers are
inherently new programs, they are simply required to write
conformant headers that are conformingly folded. There is no
need to rewrite them.
Multiple signing:
While there needs to be some capacity for this, we must be wary
of adding too much complexity to make it happen. By and large
the only serious need for multiple signing is for a moderated
group, if we want the author to sign a message and the moderator
to also sign it.
There is no need for signing by both an injector and a poster.
Again, any posting software that signs modern and must conform
to the new spec, and that means it identifies the author to the
satisfaction of the injector, or the injector rejects it.
For poster and moderator, it's even doubtful. Combined
moderator/poster signing has merit if we wish to create a
group where the moderator is not authorized to modify articles,
just add their own approval.
The question is, how much complexity do we want to support that?
I'm not sure. However, I do know multi-signature, when supported,
should be rare.
> Signatures will typically be generated by the originators of articles
> (to prove the origin), by moderators of moderated newsgroups (to
> testify to their Approved header), by managers of mailing lists, and
> by gateways. They SHOULD NOT be generated by intermediate transports
The question comes up, if a gateway is automatic, what does it mean for
it to sign things? What security comes of that? If the gateway has
security, then of course it can sign to indicate articles passed that
security. If an article is already signed in a checkable fashion, however,
does a gateway have to further sign it if it performed no other security
check on it?
> when new, hitherto unsigned, information is added. Moreover, the set
> of headers included within the signature SHOULD be no more than is
> necessary to achieve the security desired.
Why? Why would you not want to sign as much as you possibly can?
Is there any reason you would leave things deliberately unsecure when
you could easily have made them secure?
>
> NOTE: It will be observed that no provision has been made to
> include the bodies of an article or of its sub-parts in the
> signature. If (as will indeed often be the case) it is required
> to attest that the body (or sub-part) dispatched along with the
> set of headers is the same as the body that was delivered at the
> far end, then the proper procedure is to construct a Content-MD5
> header [RFC 1864] for that body (or sub-part) and to include
This is fine, except again, as long as the body has meaning (which it
does for all but a few control messages) why would you ever want to
not secure it, if it's easy to do so?
>
> The Verified header is intended to be added to an article by an agent
> through which the article passes, and serves as an assertion that the
> corresponding Signed header has been cryptographically verified by
> the person or entity identified in the name-addr (or otherwise if the
> "FAILED" value is present). The addr-spec contained in that name-
> addr MUST be a valid email address by which that person or entity may
> be contacted. The original Signed header MUST NOT be removed from the
> article. The Verified header (supposing it is the only one present
> with that particular DIGIT9, if any) MAY itself be included in a
> further Signed header added at the same time.
I still strongly oppose the concept of passing on articles that show as
forged or mangled. This defeats most of the value of signatures,
particularly in control messages and moderated groups where we want
them the most.
The concept of an article being verified should be inherent. If the
article is present on your news server, and your news server checks
signatures, then it is verified, period.
Could somebody explain what they think is the great value in having
and propagating articles with invalid signatures? Other than to track
signature bugs, which we can surely do another way?
Signature checking can't be totally end to end because it is not practical
for clients to manage a CRL. But it should be very nearly end to end,
ie. done by trusted nearby servers, and they should not be passing on or
storing articles with invalid signatures, they should either discard
them or divert them to a special "failed sig" channel for debug purposes.
The first goal of signatures is to verify control messages, which is done
by servers, so that is end-to-end. Clients never see them. The second
goal evidenced is to secure moderated groups. It serves almost nobody
to have all the existing newsreaders still see all the forgeries in
their moderated groups, and to have to suck down all the headers and
do checks for verified headers placed in the overview and filter them
out.
What possible justification could there be for that design?
The third goal of signatures, as I see it, is to create new types of
secured groups that are not moderated but have some level of security.
I can barely, just barely, see an argument for migrating to these through
the partial security suggested here, but it's a pretty thin one.
> NOTE: The Verified header is also useful in the case that a
> gateway (or a moderator) makes some change to an article that
> renders an original Signed header invalid. Such a gateway can
> therefore certify that the original form of the Signed header
> had been verified, and can then resign the article (including
> his added Verified header). Likewise, a site (such as the
> originator's own server) with a well known public key can verify
> and resign an article whose originator's public key may be less
> well known. However, Verified headers SHOULD NOT be added as
> routine by other intermediate sites.
If a signature is invalidated, it is only so many random bits. There is
little purpose in including it. The only thing I can see it doing
is allowing the author to come forward with the original later, and prove
that it is the original. There are other ways of doing that.
Generally, chains of signing are less secure than end to end authentication.
As such, why would you design something where you check a signature
and sign that you checked it when better systems are well known and
available to do it end to end? I don't expect my key to be known, but
I get my *key* signed by one that is known. That scales a lot better than
weak-link-vulnerable chain signing of actual articles.
>
> It is a sad fact of life that those implementing agents for handling
> Netnews and Email cannot resist the temptation to "improve" articles
> passed through them by rewriting headers that are thought not to
> conform to some real or supposed standard. Experience shows that, in
Right, but here's our chance to fix that. As I point out, any signed
article is inherently checked by modern software that is required to
ahere to modern specs. Our problem in the past was that people could
tinker and get away with it.
Signature fixes that. Tinker, and your software fails to propagate
articles. End of story. While minor, unnoticed modifications spread
like weeds, signatures assure that headers remain consistent end to end.
You can't get change upon change upon change. And by breaking *all*
changes, errors don't go undetected.
> It is a further sad fact of life that agents which make such changes
> are not going to go away just because some standard says so.
Correct, but they will go away if they cease to interoperate entirely.
Signature checking makes interoperability a binary issue. You pass the
bits through in a form that meets the rules or you don't play.
Now I understand that in E-mail that may not be the right goal. But I
am looking at USENET, and I think we can reach that goal in USENET.
We aren't going to get the signing of E-mail to change here. There are
already a bunch of competing E-mail signing systems already in play.
If we define signing for USENET, it will spill over into E-mail if we
do it right, but not by fiat. Gateways between USENET and mail will
have to move from USENET signing systems and mail signing systems if
they are forced to by broken mail software. Yes, they may have to
put in a verified style header as a reluctant alternative, though we
don't really need to worry about it in USENET.
Providing a perl canonicalizer isn't really going to help because few
of the signature checkers will be written in perl. One could use perl
to check control messages, but it doesn't scale to doing even all
moderated groups.
Finally, the whole proposal has no certificate system. It's not going
to go very far without one.