Re: Call for tests: pkg_install-renovation

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

On Mon, May 26, 2008 at 08:02:26AM +0100, Alistair Crooks wrote:
> > I would welcome any help in this area, my nroff-fu is still weak.
> > Basically, to create signed package for private use, run the CA.sh
> > script from OpenSSL first.
> 
> nroff-fu is not needed.  Plain text will do.

OK. Attached draft needs some more work, but should answer the most
important questions. Special thanks to Tonnere for the discussion.

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 neykey.pem (private key), those
will be given to pkg_admin sign-package as arguments

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.