Re: Call for tests: pkg_install-renovation

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

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

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

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.

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.


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.


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 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.


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"
- "X509v3 Basic Constraints" should list "CA:FALSE" for all keys that are not 
allowed
  to sign further keys.