Hi,
In your test case which fields actually differ between the
old root CA certificate and the new root CA certificate?
P.S.
Please do not use those 3 letter abbreviations of certificate
field names, very few people know those abbreviations.
For the benefit of other readers:
I think Ashok was referring to AuthorityKeyIdentifier and
SubjectKeyIdentifier fieldsbeing absent from the root
CA certificates in his scenario.
On 9/24/2012 6:26 PM, Ashok C wrote:
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
<mailto: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
<tel:%2B45%2031%2013%2016%2010>
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
<mailto:openssl-users@openssl.org>
Automated List Manager majord...@openssl.org
<mailto:majord...@openssl.org>
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
