W dniu czwartek, 9 października 2014 02:12:47 UTC+2 użytkownik Erwann Abalea napisał: > Bonsoir, > > > > Le mardi 7 octobre 2014 13:20:48 UTC+2, siuda...@gmail.com a écrit : > > > W dniu wtorek, 7 października 2014 00:19:39 UTC+2 użytkownik Erwann Abalea > > napisał: > > > > > I agree that AKI is not a way to limit scope of CRL. > > > > Good. > > > > > The problem you noticed concerns building cert path during validation CRL > > (because CA and CRL are identified by name). Do you think that more > > applications and browsers are recognizing IDP (and matching between > > CDP/IDP) than AKI ?? There is no security hole in KIR scanario, because, > > even if someone will substitute CRL, it will be not verified by higher > > level CA (wrong signature). > > > > CA's duty is to produce signed elements (certificates and CRLs) according to > RFC5280. > > RP's duty is to verify those signed elements according to the same standard. > > > > Don't mix the two and lower CA's behaviour because you assert that your RP > will reduce their checks. > > > > > We have to also remember that AKI must be included in CRL, use od IDP is > > optional. > > > > IDP is not optional in KIR scenario, and AKI offers no support here. > > > > I reproduced a test-case similar to KIR's scenario: > > - root CA cert and empty CRL > > - sub CA "generation1" and "generation2" (those are the 2 certificates for > the same CA, with the same name, they only differ by their keys) > > - sub CA "generation1" delivers a certificates for an EE and revokes it, > produces a CRL (with AKI) containing this certificate > > - sub CA "generation2" produces an empty CRL (with AKI) > > - EE signs a message > > - a relying party tries to validate this message, with complete path > validation and CRL checks > > > > If the relying party is given the CRL produced by Sub CA "generation1", the > validation fails (certificate is revoked). > > If the relying party is given the CRL produced by Sub CA "generation2", the > validation passes. > > AKIs are followed, RFC5280 validation path is followed. > > > > The relying party software is OpenSSL, which is included in nearly every > Linux distrib, along with Mozilla Root CA certificates. > > > > The sample signed message is at https://kouettland.com/SZAFIR/test.eml > > Trust store "generation1" is at https://kouettland.com/SZAFIR/verifier1.cacrt > > Trust store "generation2" is at https://kouettland.com/SZAFIR/verifier2.cacrt > > > > Run "openssl cms -verify -CAfile verifier1.cacrt -crl_check -crl_check_all > -extended_crl -in test.eml" or "openssl cms -verify -CAfile verifier2.cacrt > -crl_check -crl_check_all -extended_crl -in test.eml" and compare the results. > > > > Issuing different complete CRLs for the same scope is a security risk, > whatever the key used to sign the CRL.
Erwann, I appreciate your input, but: 1.OpenSSL cant be treated as reference application, as an oracle... OpenSSL doesnt support AKI in CRL. Are you sure that will it support IDP ?? What can we found on OpenSSL site: http://www.openssl.org/docs/apps/cms.html# in section Bugs: No revocation checking is done on the signer's certificate... Check this...Maybe it is not working as it should ? 2. I know, Openssl is great set of crypto primitives, and is in linux dist, but in reality - it means nothing... Mozilla uses its own set of cryptolibraries - JSS/NSS, they dont uses openssl Redhat in their CA and PKI services, dont uses openssl - they uses Mozilla NSS/JSS . They all supports AKI. Moreover, browsers also doesnt have any problem with correct validation KIR certs and CRL 3. KIR scenario, is encountered also in Microsoft PKI...., this was also issue in Apache MOD SSL: https://issues.apache.org/bugzilla/show_bug.cgi?id=45708 In this scenario, you also objected against AKI, but Apache solved this bug, using AKI, like KIR want. Microsoft also uses AKI, not IDP. So - rfc5280 says one thing, market revised it and uses AKI, and only AKI. 4. Lets consider OCSP - all responders uses CRL as backbone. What we have in OCSP request? AKI. IDP is completely useless. 5. RFC5280, 6.3 CRL validation -read it..- conforming implementations that support CRL are not required to implement this algorithm... 6. I respect standards, but they should serve the market,not in opposite way. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
