Only the private and public keys are different.. Rest of the fields are same.. Basically I am simulating the trust anchor update related scenarios.. And yes Jacob, thanks for indicating, I'll make sure I don't use such abbreviations from here on..
Ashok On Sep 24, 2012 11:25 PM, "Jakob Bohm" <jb-open...@wisemo.com> wrote: > 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 <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 >
