From: Brad Templeton (brad@templetons.com)
Date: Fri Jul 17 1998 - 01:57:47 CDT
On Thu, Jul 16, 1998 at 09:26:47PM -0700, Russ Allbery wrote:
> For whatever it's worth, I think (a) is a clear win for Usenet and I'd
> hate to try to sell (b) to anyone whether it's an IETF standard or not.
> If the signature isn't embedded in the header, we'll get a huge backlash
> from readers who don't want to see all the MIME cruft.
That's why I came up with it at first, but I wrote two specs, one each way,
on my web pages www.templetons.com/usenet-format.
Don't be too sure that "mime cruft" is that big a problem. MIME's pretty
old now. The newest release of almost every major newsreader already
supports it, and probably 80% of people on USENET are using a reader that
can handle it today. Admittedly they would, with such readers, see the
headers repeated at the bottom of the article, but this is not so big a deal.
multipart/signed makes it very clear what you hash. You hash part 1.
This is good not just because it's easy to code. It's very hard to get
it wrong. The addition of new headers or variant headers (like path)
does not risk breaking the system or need special treatment. You can
move from news to mail and back again, etc.
Still, I tend to the first one I laid out for the other reasons I described.
But it does mean you need to know what not to hash, and that it's very hard
to add new headers later (ie. at the moderator) because it must be certain
they will not be hashed. Specifying what *to* hash, as in pgpverify, is
not secure, it allows people to add headers, changing the meaning of your
article withour your assent.
>
> Noting that most existing signature protocols that I'm aware of already
> mix (b) and (d) together and sometimes (c) into one string, so we may not
> have need to deal with that ourselves.
They mix the key name with the signature created with the key? That's not
strictly possible unless they have a way of parsing it. You need to
extract the key's name to look up the key (be it in cert or on disk.)
>
> I still don't like this. I don't think it's the proper role of a
> certificate authority to get into the authorization business. I think it
> should be certifying *who* someone is and leave the question of
> permissions to other people.
Ah, you have entered into the greatest battle in the certificate business.
The identity certificate (which you are championing and which there is the
X.509 standard for) and the attribute certificate (which I, and many others,
prefer.) Are you aware of the great debate on this or just coming into
it anew? It should be noted that some people view an attribute cert
as an adjunct to an identity cert, while I feel they are disjoint.
CAs can only do what you trust them to do. Certify identities or certify
attributes. Attribute certificate systems can certify identities (they
are just another attribute.)
Attribute certificates certify what you really want to certify. I don't
want to certify that you are Russ Albery. Who cares about that? What I
want to certify is that you're trustworthy to approve articles in
your moderated newsgroup.
Anyway, the system I've designed can certainly be used as an identity
certificate system as a degenerate case, certifying only that keyholders
match e-mail addresses, with other certificates perhaps linking e-mail
addresses with delegated capabilities.