Bug 1653863

commit c75543ab71458fa60dbb2c2da1ce063243eac8c5 (HEAD -> master, ladycfu/bug1653863-CMC-tools-keyID-master, bug1653863-CMC-tools-keyID-master)
Author: Christina Fu <cfu>
Date:   Fri Nov 9 11:06:57 2018 -0800

    bug 1653863 tools supporting CMC requests output keyID needs to be captured in file
    
    This patch adds code in both CRMFPopClient and PKCS10Client to automatically
    write the private key id into a file named <output>.keyId so that
    they can be featched later for CMCRequest
    <output>is the name of the file specified with the "-o" option.
    
    This patch also changed all references from "CMC self-test" to
    "CMC shared secret" instead.
    
    A test feature is also added to CMCRequest.
    
    fixes https://bugzilla.redhat.com/show_bug.cgi?id=1653863
    
    Change-Id: Iaf2772be54f9937da456655cdec688f13f6e8b71

DOGTAG_10_5_BRANCH:

commit cb99e112b9421f6fe98b4ac5ab5885c28ee958c3
Author: Christina Fu <cfu>
Date:   Fri Nov 9 11:06:57 2018 -0800

    bug 1653863 tools supporting CMC requests output keyID needs to be captured 
    
    This patch adds code in both CRMFPopClient and PKCS10Client to automatically
    write the private key id into a file named <output>.keyId so that
    they can be featched later for CMCRequest
    <output>is the name of the file specified with the "-o" option.
    
    This patch also changed all references from "CMC self-test" to
    "CMC shared secret" instead.
    
    A test feature is also added to CMCRequest.
    
    fixes https://bugzilla.redhat.com/show_bug.cgi?id=1655951
    
    Change-Id: Iaf2772be54f9937da456655cdec688f13f6e8b71

Testing procedure documented here:
* https://bugzilla.redhat.com/show_bug.cgi?id=1655951#c3 - CC: tools supporting CMC requests output keyID needs to be captured in file [rhel-7.6.z]

*** Bug 1588599 has been marked as a duplicate of this bug. ***

Verified on RHEL7.7 using

[root@pki1 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.7 Beta (Maipo)

389-ds-base-1.3.9.1-8.el7.x86_64
pki-ca-10.5.16-2.el7.noarch
pki-kra-10.5.16-2.el7.noarch

[root@pki1 test]# CRMFPopClient -d . -p Secret123 -n "cn=Christina Fu, uid=user1a, ou=yesPOP" -q POP_SUCCESS -b kra.transport -a ec -v -o crmf.pop.req
Initializing security database: .
archival option enabled
Loading transport certificate
Parsing subject DN
RDN: OU=yesPOP
RDN: UID=user1a
RDN: CN=Christina Fu
Generating key pair
Keypair private key id: 6efe13c0b59b7af9281cefd4c88a151c0541490a
Using key wrap algorithm: AES KeyWrap/Padding
Creating certificate request
Creating signer
Creating POP
Creating CRMF request
Storing CRMF request into crmf.pop.req
Storing CRMF request key id into crmf.pop.req.keyId

[root@pki1 test]# cat crmf.pop.req.keyId
6efe13c0b59b7af9281cefd4c88a151c0541490a

==============================================================
[root@pki1 test]# PKCS10Client -d . -p Secret123 -a ec -c nistp256 -o p10-ec.req -n "CN=cfuEC"
PKCS10Client: Debug: got token.
PKCS10Client: Debug: thread token set.
PKCS10Client: token Internal Key Storage Token logged in...
PKCS10Client: key pair generated.
PKCS10Client: CertificationRequest created.
PKCS10Client: b64encode completes.
Keypair private key id: 2089a0b546ff967daee448881d649e2df594e759

-----BEGIN CERTIFICATE REQUEST-----
MIHKMHICAQAwEDEOMAwGA1UEAwwFY2Z1RUMwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAATanJRNT/+luzczfsrUL8Xnq3QpkKRe9Odqhs+I4c/cJB2L09WdlPjSrAr2
SjR2d7AzrZgY4TgjT72wY43Y51ZYoAAwCgYIKoZIzj0EAwIDSAAwRQIgWH/FJfuz
ZNo0bw5ViDwgVqsgYamZ4rQsrlHwjwd1H3oCIQCWI+e7z8f4ej35vecPtBLADTJe
paw4ZLLr49/khfX9bQ==
-----END CERTIFICATE REQUEST-----

[root@pki1 test]# cat p10-ec.req.keyId
2089a0b546ff967daee448881d649e2df594e759

[root@pki1 ca]# date
Wed Jun 12 03:33:13 EDT 2019
[root@pki1 ca]# pwd
/var/lib/pki/topology-01-CA/ca/profiles/ca
[root@pki1 ca]# ls -l | grep Shared
-rw-rw----. 1 pkiuser pkiuser  5242 Mar 18 20:13 caECFullCMCSharedTokenCert.cfg
-rw-rw----. 1 pkiuser pkiuser  5231 Mar 18 20:13 caFullCMCSharedTokenCert.cfg

#man CMCRequest
     request.useSharedSecret
              true or false.  If useSharedSecret is true, the CMC request will be "signed" with the pairing private key of the enrollment request; and in which case  the
              nickname parameter will be ignored.

#man PKCS10Client
In addition: -y <true for adding SubjectKeyIdentifier extensionfor cmc Shared Secret requests; false otherwise; default false> To be used with 'request.useSharedSecret=true' when running CMCRequest.

caECFullCMCSharedTokenCert.cfg
caFullCMCSharedTokenCert.cfg
#policyset.cmcUserCertSet.1.constraint.name=CMC Shared Token Subject Name Constraint

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2228