On 9/13/2012 3:41 PM, Charles Mills wrote:
Would it make sense to delete the expired certificate from the Windows
store? Duplicate expired/non expired CA certificates sounds to me like a
problem waiting to happen.
/Charles/
Windows has built in support for using and checking time stamping
countersignatures in PKCS7 signatures. If the countersignature is
signed with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its
certificate is checked as if the current time was the one certified
by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).
Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).
P.S.
I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.
The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
1.2.840.113549.1.9.6 = counterSignature
unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute). The countersignature specifies the
signed data type to be "1.2.840.113549.1.7.1=data", but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6). The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.
On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:
POST url with "Accept: application/octet-string" "Content-Type:
application/octet-string" The post data is Base64 of DER of
SEQUENCE { -- Attribute
type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
content Type OID -- must be 1.2.840.113549.1.7.1 =data
content [0] EXPLICIT OCTET STRING
-- must be the outer encryptedDigest
}
}
}
Response if successful is a 200 HTTP status with "Content-Type:
application/octet-string" and a value which is Base64 of DER of
a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)
This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
