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.
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.
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.
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
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
