Thanks Jacob, but in the three scenarios you mentioned, the first one *does not* seem to be supported by openssl 1.0.0*. I think that was the subject of this email thread in the beginning.
>>1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. Here, if the expired one is encountered first, openSSL does not lookup the non-expired CA certificate. This is then a bug right? -- Ashok On Tue, Sep 25, 2012 at 12:33 AM, Jakob Bohm <jb-open...@wisemo.com> wrote: > Does that work with any other serious X.509 validation toolkit? > > To make this work (assuming the old root CA cert has not yet expired), the > validation code will need to actually verify the End Entity > certificate against both public keys, which effectively reduces the > algorithm security by allowing twice as many bit strings to be > accepted as valid. > > Filtering based on criteria that do not involve actual signature > validation would be cryptographically safe, but when falling back to > validating against multiple signatures, extra care is needed for the > above reason. > > As for trust anchor update scenarios, I know of 3 different scenarios > that should be accepted by any good X.509 validation algorithm: > > 1. Changing expiry or other attributes while keeping the key. > Here the CA issues a new self-signed certificate with updated > attributes but unchanged key. > > 2. Changing the CA key when the old key has *not* been compromised. > Here the CA generates a new key and issues two certificates for it: > > A. A self-signed new root with a serial number or other variation > in one of the subject name components. > B. A certificate for the new key and the same subject and (optional) > SubjectKeyIdentifier as A, but issued by the old root certificate > identity and key. > > End Entities with certificates issued with the new key reference the > modified subject as authority and should be configured to supply the > transitional "B" certificate in chains sent to other end entities. > Such end entities should then succeed validating against either the > old root CA (via the B certificate supplied) or the new root CA > (via finding it as a locally configured trust anchor). > > This is the scenario used by at least one major CA for its upgrade > to larger keys, and SSL servers that forget the B certificate in > the supplied chain get rejected by at least one common platform > version (Android 2.3) because it only includes the old trust > root in its store and uses an underdocumented BouncyCastly store > format thus preventing the efficient deployment of the new A cert. > > 3. Setting up the CA to have keys for more than one algorithm (such > as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the > certificate validation could SHOULD (but might not) match issued end > entity certificates to the trust anchor by also comparing > signatureAlgorithm in the issued certificate against > subjectPublicKeyInfo.algorithm in the candidate issuer cert from the > store. > > However because not all clients are going to do that, it is still > recommended that the CA follows the scenario 2 procedures, except > when it is a test CA for verifying handling of this scenario in > X.509 implementations. > > > On 9/24/2012 8:01 PM, Ashok C wrote: > >> 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 >> <mailto: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> >> <mailto: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 > 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 >
