Hi,
One more observation was made here in another test case.
*Configuration:*
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.
*Test case 1:*
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem > combined.pem;cat newca.pem >> combined.pem
*Test case 2:*
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem > combined.pem; cat oldca.pem>>combined.pem
Test case 1 does not seem to correct behaviour as the trust store contains
newca.pem. Ideally the lookup needs to verify ee.pem with the newca.pem.
P.S. The CA and EE certificates are v3 but do not contain AKI or SKI fields.
--
Ashok
On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:
> 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
>
