Enhance tkstool for capabilities and security
This simple ticket is to fix tkstool to allow it
to create the master key with the proper flags to make
the key data private such that it can't be easily viewed when
using tools to print out sym keys on the token.
Fix tested on the "internal" token by trying the various tkstool
cmds to make sure having the key private does not cause issues.
Also tried a simple key changeover operation with tpsclient to make
sure that symkey can still do what it needs to do witht the master key.
Further testing with a full hsm will be required.
The goal was the create the key with the same flags that are used with the
previous "PK11_GenKeyOnToken" (name approx) is used. This version had no
flags and created a default set. This fix uses the version With flags and
does what the old one did, but made sure the key is private and sensitive.
Master key can be tested by using the tool:
/usr/lib64/nss/unsupported-tools/symkeyutil -d ./ -L
The attached patch makes sure that the right authority is used to
create OCSP responses. Note that OCSP requests may ask about certs
from more than one issuer - even though this is crazy the heuristic
used is to simply use issuer of the first CertID in the request.
Note that OCSP response validation of certificates issued by sub-CAs
currently fails due to a separate issue.
The attached patch (part of the GSS-API effort) weakens several
soon-to-be-unsafe casts of the user principal object. It also adds
some commentary (in the form of TODOs) to replace hardcoded role
names with appropriate checks against authzManagers.
Pursuant to RFC 7468 the attached patch replaces instances of
'CERTIFICATE CHAIN' in PEM headers with 'PKCS7'.
Fixes ticket https://fedorahosted.org/pki/ticket/1699. I could not
reproduce any problems with `keytool' as mentioned in the ticket,
nor find cases online of programs supporting 'CERTIFICATE CHAIN' but
not 'PKCS7', so I think this is a good change to make. We can
address counterexamples if/when we have hard evidence of them :)