Bart Smaalders wrote:
Darren J Moffat wrote:
Bart Smaalders wrote:
Darren J Moffat wrote:
Bart Smaalders wrote:
This leads to the proposal of a new signature action, of the form:
signature public_key=hash signature=value ...
where the hash represent the packaging hash of the file containing
the public key down-loadable from the originating repository;
This looks quite useful as a way to simplify the management of the
trust anchors. However we will need an administrative interface to
display and control addtions/removals of the resulting trust
anchors otherwise it appears to be too easy to add random new trust
anchors.
Notice that the real action of trust occurs when you install the
package :-). Perhaps I'm missing something (I'm not very familiar w/
cryptography issues), but even if the package publisher chose to use
a different certificate to sign each package, as long as each of the
certs presented contained the correct CN and were properly signed by
a trusted CA, there shouldn't be any issues (other than downloading
extra certs and checking them). The real act of trust is accepting
packages from the specified CN.
Right, so how is the list of trusted CA's specified ?
Is it tied to a repository/authority ?
The simplest model is just to expect a Verisign-signed certificate -
simple for us, not workable for any but corporate repos. I'd like to
work out a method that would allow more of a web of trust model for
community repos. This isn't at all worked out yet, obviously.
Using a root CA like verisign is only useful for establishing the
identity of parties. A mechanism is still needed to control which
parties are acceptable on the system and some minimum set will be needed
to install from a repository without irresolvable dependencies, etc.
Using java (webstart) as an example, verisign is one of the many
known CAs that can verify the identity of the signer, but the user is
then asked whether to assign needed privileges to the code signer.
Note that it would be pretty simple to permit the addition of a CA
per repo when that publisher is added to the system; the question
becomes how one ensures that at that time one isn't subject to a
man in the middle attack. After initial acceptance, packages from
that repo signed w/ a cert traceable to that repo's CA would be ok.
I think a system should have a single set of root CAs in /etc/certs
that should always be the mechanism for establishing identity as far as
the system is concerned. To use a given repository one probably needs
to decide if one trusts an identity established by a code signing
certificate (that should be anchored by something in /etc/certs) that
signed a metadata package that includes that lists the required identity
anchor CAs and an "acl" for other code signing identities anchored by
that list which one must trust.
A repository with a identity anchor that can't be confirmed using
/etc/certs can't be used until /etc/certs is updated (perhaps from
another repository,) otherwise one accepts/installs the provided acl
into the IPS configuration and starts using the repository.
Is it separately maintained by pkg(1) ?
It needs to be in the admins control but at the same time
out of the way for the majority of people.
The list of trusted CAs for package install is most definitely not
the same as your browser uses for SSL/TLS.
Since certificates have a purpose in them I don't think a system
wide set of root CAs is actually a problem unless we conflate
identifying a party as a code signer who is whoever they say they are
with granting them permission to install software.
-Will
The default OS install (from the network or CD media) should have
which ever CA's as trust anchors are needed for verifying the content
of the default set of packages and the default authority.
Yup - that's been the plan.
- Bart
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
