Re: Call for tests: pkg_install-renovation

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Tue, Jun 10, 2008 at 05:37:04PM +0200, Joerg Sonnenberger wrote:
> On Sun, Jun 08, 2008 at 12:03:24AM +0200, Joerg Sonnenberger wrote:
> > OK. Attached draft needs some more work, but should answer the most
> > important questions. Special thanks to Tonnere for the discussion.
> 
> Another revision. Thomas pointed out a typo and hit an issue with
> openssl.cnf, so mention it explicitly.
> 
> Joerg

Thanks, Joerg, this is excellent progress.

> Use of digital signatures in pkg_install
> ----------------------------------------
> 
> (1) pkg_vulnerabilities: list of known vulnerabilities, provided by
>     the pkgsrc security team and updated regulary
> (2) binary packages: check who provided binary packages

(3) verify that the package has not been modified in any way
 
> For (1) gpg is currently the only choice. After pkgsrcCon (?) a PKCS7 
> signature will be added as well. With the pkg_install-renovation branch,
> PKCS7 is the only supported verification mechanism for (2) and preferred
> for (1) once the infrastructure exists.

This needs to be discussed more fully, timelines (even relatively obscure
ones like the above) need to be omitted for documents which may live a
while, etc.
 
> PKCS7 is a format to use RSA public key cryptography with X509
> certificates. Those are commonly used for SSL. X509 implements a
> hierachical trust model. For this purpose it means that one or more
> certificates are installed and marked as trusted. A certificate used for
> signing a binary package or pkg_vulnerabilities will have to be included
> in the list to be trusted OR it must be itself signed by a trusted
> certificate. The original list is called the TRUST ANCHOR.
> 
> Optionally, a second list of certificates can be provided to fill gaps.
> Let's assume A is a trust anchor and C is used to sign a package. C
> itself is not signed by A, so it won't be trusted. Instead, there's a
> third certificate B; and C includes a signature with B. The certificate
> chain file can now provide B signed by A. This gives a certificate chain
> of C -> B (included in the package) -> A (with the chain file) and the
> signature is valid and trusted.

I'd like to see this paragraph expanded greatly.  Don't get me wrong -
it's great to have this, but I think we need more, much more.  We need
worked examples.  We need to show how the trust passes through the
certs, we need to get away from "A", "B", and "C", or the
mind-numbingly twee nomenclature of "Alice", "Bob" and "Mallory" that
the security types hold on to like a comfort blanket.

> Practical implications for pkgsrc users:
> - get the pkgsrc-security certificate and point CERTIFICATE_ANCHOR_PKGVULN to 
> it
> - get the certificate used by your bulk builder and point
> CERTIFICATE_ANCHOR_PKGS to it
> - at some later point a CA for pkgsrc might be created, in that case it
> will serve as certificate for both purposes; a list of all certificates
> will be provided in that case to point CERTIFICATE_CHAIN to.

Again, we need to expand this:

How does an ordinary user get the pkgsrc-security certificate?
How do you get a certificate from a bulk builder? Where are they?
How do you know it is genuine? What if I am a bulk builder? How can
I provide my certificate to others? Is there a canonical place in
the pkgsrc ftp hierarchy for the cert? Do we need to have a Certs
directory on the same level as All?

> How to create your own keys:
> - find the CA.sh script shipped with OpenSSL
> (/usr/share/examples/openssl on NetBSD)
> - run CA.sh -newca to create the root certificate, the meta data is only
> for human beings, so feel free to provide sensible input
> - in demoCA/newcerts/00.pem is the public key, you can use that as trust
> anchor
> - create a subkey using CA.sh -newreq, followed by CA.sh -sign. This
> creates newcert.pem (public key) and newkey.pem (private key), those
> will be given to pkg_admin sign-package as arguments

The notion of a "sub-key" needs to be explained. Possibly public key as well,
since up to now, all the talk has been about certificates.
 
> The location of demoCA might change depending on your openssl.cnf
> (typically in /etc/openssl).
> 
> If not sure about the process, read one of the many, many documents on
> the internet. The above is the bare essential.

Well, if we can't document this ourselves, it doesn't deserve to be
there. We need to document the process that a user needs to go through
to verify binary packages. References to other documents are good,
but we need to document the process ourselves fully.

> How to verify a certificate:
> - decode the data with "openssl x509 -text -noout -in newcert.pem"
> - "Issuer" is vouching for the identity (and reliability) of "Subject"

s/reliability/integrity and provenance/

> - "X509v3 Basic Constraints" should list "CA:FALSE" for all keys that are not 
> allowed
>   to sign further keys.

Yeah, I know it's not our job to document all the deficiencies in the 
3rd party apps that we're using for this, but for many, this will be their
first experience of certificates, although they have probably been using
gpg for a while, and have signed others keys.

Regards,
Alistair