[1981] in Kerberos_V5_Development
Re: alternatives for signing krb5 1.0
daemon@ATHENA.MIT.EDU (Mark Eichin)
Tue Nov 19 20:28:35 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Mark Eichin <eichin@MIT.EDU>
Date: 19 Nov 1996 20:27:52 -0500
In-Reply-To: "Barry Jaspan"'s message of Tue, 19 Nov 1996 14:41:03 -0500
> perform (they would have to have pgp to verify the signatures, and an
> md5 program to compute the checksum, and they'd have to match the
> checksums visually themselves).
I don't see that this is any different than simply providing a
collection of "detached signatures" on the release itself from
everyone who wants to. (pgp supports detached signatures directly, of
course.)
There's a semantic difference at issue here, though; if I sign the
release, I'm saying "I think that's the release" -- if I sign the
one-shot key, I'm saying "I think that one-shot key was managed
correctly, and was used appropriately." without *directly* asserting
anything directly about the release. Sure, the transitive
relationships appear to reach the same point, but how you get there
makes some amount of difference...
I'd be willing to attend an in-person wipe-the-disk offline signing,
and then sign the resulting key. Then again, we clearly need to do
*something* since we've done nothing at all with previous releases...