Interfacing key archival CMC request to a non .net CA
From: Jean-Marc Desperrier (jmdesp_at_alussinan.org)
Date: 10/13/03
- Next message: Christopher Kish: "RE: AZMan auditing"
- Previous message: Valery Pryamikov: "Re: Using certificates from CryptoAPI in custom operations"
- Next in thread: Vishal Agarwal[MSFT]: "Re: Interfacing key archival CMC request to a non .net CA"
- Reply: Vishal Agarwal[MSFT]: "Re: Interfacing key archival CMC request to a non .net CA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 13 Oct 2003 16:57:08 +0200
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 ?
- Next message: Christopher Kish: "RE: AZMan auditing"
- Previous message: Valery Pryamikov: "Re: Using certificates from CryptoAPI in custom operations"
- Next in thread: Vishal Agarwal[MSFT]: "Re: Interfacing key archival CMC request to a non .net CA"
- Reply: Vishal Agarwal[MSFT]: "Re: Interfacing key archival CMC request to a non .net CA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|