>Looking further ahead, I have longer-term objectives relating to
>execution-time validation of per-file signatures, as Windows can do.
>The q&d way to do this now is by preloading hashes into veriexec from
>a signed document using userland tools, and perhaps it will stay that
>way.

veriexec with signed signature lists seems a reasonable approach to me.

>In the meantime, I'm more than happy to talk first about signing
>"installation containers" of various kinds.

Yes, once you have the signature/verify stuff sorted out, what you
choose to sign is a minor issue.

>> We're using a certificate based trust model - which is quite
>> appropriate to this case, since its the vendor's (eg NetBSD) code
>> wanting to confirm that the software to be loaded came from the
>> vendor.=20
>
>Yes, although we'll at least potentially want some slightly
>finer-grained distinctions within that - releases, pkgs, perhaps
>patches and security updates.  This helps avoid problems with key
>disclosure if everything must be signed with the same key.

Ah but that's the whole beauty of a cert based model.
Eg.  you want a hierarchy of certs like (names suck I'm sure ;-)

	NetBSD-RootCA
		|
	______NetBSD-devCA ________
	|	    |		   |
 NetBSD-releaseCA NetBSD-pkgsrcCA  NetBSD-securityCA
	|		|		|
	NetBSD-2.0	<whatever>	SO


The extra levels of hierarchy cost very little and allow for future
flexibility.  At minimum, the above allows for regularly replacing the
keys being used for signing releases, pkgs and security-advisories.
[important if using DSA].

Anyway, the good bit is that provided the user has one of the CA certs
that sits above a particular signing cert (the cert associated with a
signing key - eg NetBSD-2.0 above), then they can verify the signature
of an otherwise unknown key.  Its the NetBSD-RootCA that they need to
trust (at least wrt signatures relating to NetBSD).

With this model, the vendor pays the price of all the design/setup
hassle, the user can be totally oblivious since it all "just works".
Ok, a sufficiently paranoid user will be paying attention to CRL's -
Certificate Revocation Lists, but the majority of users will just
click "install" and think nothing more about it.

>In my work, I have used the "openssl smime *" commands, rather than
>working with the keys and formats quite so directly.  There are
>several other reasons for this, but the major one is that it handles
>all of the container cert chain and encoding issues you discuss for
>you.  It's been appropriate for my needs so far, but might be less
>directly applicable for this discussion (more below).

Yes, smime was one option that we considered, but it seemed to be very
particular about the format of its input and the resulting signatures
end up being very bulky.  Of course I may have just been using it
wrong - at first blush it sounded good.

>I have mumbled a number of times about volunteering to run a
>NetBSD.org CA.  I would be happy to do so if it helped encourage these
>efforts and allowed other folks to concentrate on using the certs
>rather than getting overly-wrought in these issues.

Indeed, I used to run a low-assurance CA - just to make it easy for
folk to get "realworld certs" for testing SSL apps (like my SSLrsh ;-).
I ran a more serious CA using the same setup too, and just finished
coaching the setup of another.  Getting the CA stuff setup is one of
the biggest hurdles - depending on the paranoia level to be met.  Once
its done though the rest is pretty simple, and you don't have to go to
any key signing parties.

>> If the trust store (eg /etc/certs/) contains CruftyCA.pem  actually it
>> needs 21b00b1d.0@ -> CruftyCA.pem since it is the hash of the Issuer
>> name that is used for lookups, then any certificate issued by
>> CruftyCA will verify successfully.
>
>That's something that we'd need to include in the appropriate
>distribution of the release that would start relying on these
>signatures.

Yep, and the fingerprints of the certs should be included on the
web pages etc.

>As for packaging formats and signatures, there are a number of options
>and partially conflicting suggestions.  My #1 requirement in the "just
>in case we don't get it right" category is that, whatever format we
>choose, supports multiple independent signatures.  From a policy point

Yes, detached signatures are good that way.

>For the case of key management, it's the biggest downfall of the x.509
>cert format, compared to pgp.  GPG allows that inherently, which is a
>good thing, and something we wouldn't want to "lose" otherwise -
>though it does complexify the key trust decisions.=20

The web of trust model is a good one for apps like peer to peer e-mail
signing and such, but for something simple like distributing s/w the
complexity is not worth it - except to folk who already use have
already adopted that model.

>For the case of container files, we can of course always use a number
>of separate detached .sig files, under any format.  That might be an
>easy place to start.

Yes.

>If we want to build sigs into the binary package stream format, or for
>that matter the ELF executable format, just please remember to allow
>room for more than one sig.

A reason I like the idea of veriexec with signed signature lists.

>As far as implementing this with C and the openssl library interface,
>sorry - I'll be of no help to anyone.  For all such programming work,
>I turn to Java, JCE, and bcprov for the crypto, and XML-DSIG for the
>container formats.

Which is another reason its good to stick to basics.  The signature I
generated in my example, would be just as easy to verify using a
simple java app.

>Which leaves the implementation of policy choices and implementation,
>which is always the harder part than getting the basic file formats
>and crypto routines going.  That's where most systems fall down or
>have weaknesses, and where careful design effort is warranted, which
>is why I'd also like to deemphasise discussions of particular
>technologies before the objectives are clear.

Absolutely, couldn't agree more.
--sjg