Re: Interfacing key archival CMC request to a non .net CA

From: Vishal Agarwal[MSFT] (vishala_at_online.microsoft.com)
Date: 10/17/03 

Date: Thu, 16 Oct 2003 15:40:33 -0700

Hi,
If xenroll is used to construct the CMC request and attach the encrypted
private key for key archival on the server, then no, a standard PKCS 7 is
not sufficient to install the issued cert.

Xenroll expects a response from the CA that consists of a CMSG_SIGNED PKCS7
with a data content OID of szOID_CT_PKI_RESPONSE (1.3.6.1.5.5.7.12.3) and
the data content must be an ASN.1 encoded CMC response.

A Tagged Attribute array element in the CMC response data should contain an
attribute OID of szOID_ENCRYPTED_KEY_HASH (1.3.6.1.4.1.311.21.21), with a
value that consists of an OCTET string wrapped SHA-1 hash of the encrypted
private key blob sent to the server.

If xenroll doesn't see the correct hash value in the response it will reject
the response and not install the new certificate.

The PKCS7 carrying the CMC response from the CA is signed by the CA.

By default, the communication protocol between the client and CA server is
authenticated to ensure that the data being submitted is going to the
intended CA and that the data returned is from the same CA.

Windows 2003 with Windows XP clients should by default be using
authenticated and encrypted communication over DCOM.

A Windows 2003 CA can be configured to *require* encrypted DCOM access, or
to disable all but local machine client access, if necessary.

If the communication protocol in your environment is not authenticated, then
we recommend you add an additional step to verify the CA's signature on the
PKCS7 response prior to calling xenroll to install the response.

An xenroll-generated PKCS7 (with CMC content) certificate request that
includes the encrypted private key for archival on the server, includes the
encrypted private key as an un-authenticated attribute attached to the
primary signature. It is not stored as an "extension", a term which usually
refers to extensions inside a certificate.

If the request is wrapped inside another PKCS7 layer as part of a nested CMC
request (for qualified subordination or part of a work flow application
process), the encrypted private key must be moved to the primary signature
in the outermost PKCS7 layer.

This is the only location inside the request that the server will accept an
encrypted private key.

For a new request, there is no certificate associated with the private key
(yet), so the Signer Info specifies the Key Id (sha-1 hash of the public
key), instead of identifying a signing certificate.

The private key, once decrypted on the server, will consist of a
PRIVATEKEYBLOB, similar to one exported by CryptExportKey(NULL, NULL,
PRIVATEKEYBLOB, .)

Windows XP and Windows 2003 use the same request generation code, so they
generate the same format.

Windows 2000 clients can generate CMC requests with key archival, but only
through the Windows 2003 CA server web enrollment pages that use xenroll.

In this case, they also generate the same format.

Your description of the 20 byte "header" is not sufficient for us to clarify
its use.

However, 20 bytes is the length of an SHA-1 hash, so this could be a Tagged
Attribute containing the hash of the issued certificate, the hash of the
archived key sent to the server, or possibly even a Transaction Id or Sender
Nonce, all of which are all part of the CMC response (the latter three are
also part of a request).

To understand the details of the CMC format more completely, I suggest you
use certutul.exe to dump a PKCS7 CMC key archival request as well as a PKCS7
CMC response.

If you have a specific question about the content of a request or response,
include the certutil.exe output and be specific about the output that is in
question.

If it is about an attribute, then specify the OID of that attribute.

(Note: do *not* include the hex dump of the private key from the
certutil.exe output in your posting, unless publishing the request's private
key is of no concern to you.

If certutil.exe finds the CA's private encryption key available on the
machine where it is executing, it will decrypt the unauthenticated attribute
 and display the private key as a hex dump.)

Hope it helps,

Thanks,

Vishal[MSFT] 

-- 
This posting is provided "AS IS" with no warranties, and confers no rights
"Jean-Marc Desperrier" <jmdesp@alussinan.org> wrote in message
news:%23ixrGpZkDHA.3256@tk2msftngp13.phx.gbl...
> Hi,
>
> I'm trying to interface xenroll generated CMC request including a
> private archival option with a non .net CA.
>
> Can you confirm that the ONLY method that can be used to import the
> resulting certificate is to use a CMC full response including the
> private key hash as an attribute, and that there's is NO way to use a
> usual pkcs#7 response (even including the hash inside some extension) ?
>
> Which certificates can sign a valid CMC answer ?
> Can the CA delegate the right to sign this answer, if yes, to
> certificates with which characteristics ?
>
> The page :
>
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/maintain/operate/kyacws03.asp
> shows in appendix A a request that is supposed to include the encrypted
key.
> Careful analyse of the content shows none of the element displayed
> appears to actually contain the encrypted private key. The closest match
> "Encrypted Hash" is only the size of a RSA encryption, so can not
> directly contain a full private key.
>
> In fact, request generated from a pre-2003 client include an DES3-CBC
> encrypted pkcs#7 in an extension, that can be deciphered with the
> exchange certificate. Unfortunately the format of the decrypted private
> key data is hard to understand.
> It seems to consist of a content 20 byte header, and then the key
> specific data.
> Is it possible to get documentation on this format ?
>
> The page documents the format of the request changes with a 2003 client,
> does this means the private key information will not be stored in the
> same place ? Do 2003 requests look more like a standard CMC/CRMF
> requests or stay with an included PKCS#10 and a separate element used to
> store the encrypted private key ?
>
> In fact, the request that is shown on this page does not correspond to
> what is documented on it. The document says otherMsgSequence will have a
> hash of the encrypted private key, and the shown request has an empty
> otherMsgSequence.
>
> I expect that 2kSP5/XPSP2 will use the same format as the 2003 client,
> is this right ?
>

Relevant Pages

  • Re: RSA breaking vs. factoring
    ... affects the two possible usages of RSA both for encryption (first public, ... then private key) and for signing ... are identical to encryption, in reverse order. ... Digital signature generation takes an input message (which may be quite ...
    (sci.crypt)
  • Re: CryptAPI(encryption/decryption)
    ... It seems like you're missing the Base64 decode step when trying to decrypt ... I misspelled the Private Key as Primary Key. ... Is there any variation in the encryption format in openssl compared to ... "Dylan DSilva " wrote: ...
    (microsoft.public.pocketpc.developer)
  • Re: RSACryptoServiceProvider decrypt with public key
    ... private key which my programs could decipher using a public key I've ... But since private key encryption and public key decryption isn't ... > If Alice gives Bob her public key, ...
    (microsoft.public.dotnet.security)
  • Re: CryptAPI(encryption/decryption)
    ... The openssl encrypted data format is in bigendian ... Is there any way I can import the PEM formated private key to the MS CSP ... I'm decoding the base64 encoded data before trying to decrypt. ... Is there any variation in the encryption format in openssl compared ...
    (microsoft.public.pocketpc.developer)
  • RE: PGP scripting...
    ... cryptosystems, ... In these systems divulging your private key compromises the public ... Here is a quick over view of the public key encryption routines (the ...
    (SecProg)