Hi Erwann, Thank you for your clarifications. We analysed it, and we add Authority Key Identifier extension to our CRLs. As it it mentioned in s. 5.2.1 RFC 5280 “this extension is especially useful where an issuer has more than one signing key, either due to multiple concurrent key pairs or due to changeover”. We based the value of this extension on issuer name and serial number. We checked that GoDaddy distinguishes CRLs in the same way. The CRL for the newer CA certificate is available now here http://www.elektronicznypodpis.pl/crl/trusted_ca_2013.crl. CRL for the elder CA certificate will be available tomorrow.
Regards, Przemek Od: Erwann Abalea <[email protected]> Do: [email protected], Data: 2014-10-03 20:19 Temat: Re: Re: KIR S.A. Root Inclusion Request Wysłane przez: "dev-security-policy" <dev-security-policy-bounces+certificates=kir.com...@lists.mozilla.org> Le vendredi 3 octobre 2014 15:22:23 UTC+2, Certificates a écrit : > We filed an application for Mozilla Root Certificate Program in December > 2012. We applied for inclusion existing Root CA with one sub CA. After > applying we received from Mozilla information that it is necessary to meet > additional requirements from BR. The issue needed to be improved was to > add to subCA certificate OCSP extension. We were not able to do it through > simple renewal of subCA certificate. We generated new pair of keys for CA > and Root CA issued new certifcate with required OCSP extension.This issue > was explained during first phase of our inclusion process and you can find > more detailes here: https://bugzilla.mozilla.org/show_bug.cgi?id=817994 That's right. You generated a new key pair and a new certificate for the CA. You didn't generate a new CA. > Each CA certificate has different pair of keys, serial numbers and AKIs. > They generate separate CRLs and provide individual OCSP service, There > are still valid certificates issued under the old CA, and that's why both > CAs issues separate CRLs. This is one CA with 2 certificates, and 2 key pairs. One CA, responsible for the whole population of certificates it produced, either attached to the first or the second CA certificate. You can have 2 CRLs, they MUST either be: - limited in their scope (IDP extension, for example), and each one will contain revoked certificates covered by this scope; CRLNumber can be from 2 different sequences - full scope (no IDP or equivalent partitioning extension), and each one MUST provide revocation status for the entire population of certificates issued by this CA; CRLNumber MUST be taken from the same monotonically increasing sequence, if CRLNumber has the same value in both CRLs then dates MUST be equal and revokedcertificates list MUST also be equal (if CRLNumber are different, the differences in revokedcertificates list can be explained because time passes) > Each user's certificate has > cRLDistributionPoints extension with the URLs to the apropriate CRLs. > In our opinion there is no danger of replacing CRL lists. > During CRL verification process it is checked who issued CRL and if the CA > issuer has valid certificate issued by Root CA . That's way it is > impossible during correct CRL verification process to use fake CRL. If an > application does validation in incorrect way, it will be done incorrect > regardless of whether we have 2 CA certificates or more. You're wrong. Imagine the following situation: Root CA issues 2 certificates for one CA, one of the certificates (C1) has the keyUsage:keyCertSign set, the other one (C2) has the keyUsage:CRLSign set. The intermediate CA signs subscriber certificates with the private key corresponding to C1 certificate, and it signs CRLs with the private key corresponding to C2 certificate. An RP wants to verify the status of some subscriber cert, after having validated the chain up to the root. It downloads the CRL, verifies that it is signed by the public key contained in C2 (it knows C2), and checks that the subjectName of C2 is equal to the subjectName of C1 (whence, that C1 and C2 are part of the same CA). That's a valid situation, extendable to C1 and C2 having both keyUsage:keyCertSign and keyUsage:CRLSign set, which is exactly the situation you're in. I suggest you read RFC5280 section 6.3.3 in detail, steps (b)(1) (second sentence), (f), and (g). > Regarding qualified certificates, and the QCA certs. The QCA certificate > are issued by The National Certification Centre (Polish Root CA) managed > by Ministry of Economy in accordance with the polish act on the electronic > signature. The validity period of the CA certifcates is 5 years, the users > can be valid max for 2 years. That's why every three years we receive new > CA certificate. All CA certificates are issued for new pair of keys . One > of Polish QCA which is included in Mozilla Root Certificate Program work > in exactly the same way as we do. Don't import those bugs in the TLS space, please ;) That should tell something about the value of these audits, or about the quality of the auditors. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł. Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu. The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you are not an indicated recipient, you must not copy, distribute or take any action in reliance on it. If received in error, please notify the sender by return email and delete his transmission (and any attachments) from your system. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
