Hi Przemyslaw,
1) Suspension
I can see that it's no problem for a certificate's status as shown in
OCSP or in a CRL (as viewed from outside your organization) to
transition from valid to 'Revoked' as a result of a 'suspension' within
your system.
The problem comes when you try to 'unsuspend'. You can't transition
back from 'revoked' to valid.http://www.ietf.org/rfc/rfc5280.txt 3.3. Revocation ... An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. Regards Robin Alden > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+robin=comodo....@lists.mozilla.org] On Behalf Of Certificates > Sent: 25 September 2014 14:03 > To: dev-security-policy@lists.mozilla.org > Subject: Re: KIR S.A. Root Inclusion Request > > Answers for Jeremy Rowley questions: > > A couple of notes: > 1) Under Section 3.4 and 4.9, suspension is not permitted for SSL certs > under the BRs. > > Where the BR forbids certificates suspension? The Repository gives an > answer "revoke" for suspended certificate, so it's consistent withe BR > s13.2.7. > > 2) Section 3.3 should specify when re-verification is required (at least > every 39 months). Although the CPS does say the original issuance > process is followed, I didn't this specified at the certificate lifecycle is 5 > years. Also, be aware that five year certs are only permitted until April 1, > 2015. After that, the maximum lifecycle is 39 months > > Yes, we know about this requirement. Presently, we do not issue > certificates above 2 years validity period, although we mentioned such > possibility in CPS. We do verification both for first certificate and renewal, > in particular we verify rights to domain for SSL certificates. > Our internal procedures describe this process in details. > > 3) See section 13.1.5 of the BRs for the reasons a CA must revoke a > certificate. Section 4.9 of your CPS doesn't really match these. > > The reasons for revoking subscriber certificate pointed in CSP > corresponds to the reasons pointed in BR. But if the connection isn't clear > we can clarified it more in CSP by introducing some changes. > > > 4) Archiving is required for 7 years under the BRs (5.4.3 and 5.5). > > That's a mistake in CPS. We will change it. > > 5) 6.28 should require at least two individuals acting together to activate > the private key > > It is done by two persons. It is mentioned in CPS s.6.2.2 that the secrets > are distributed among 5 persons. > CSP s6.2.6. Uploading a private key to cryptographic modules is done in > the following situations: > 1) launch of the certification authority during the system start-up; > 2) recovery of the key of the certification authority in the back-up > location; > 3) replacement of the cryptographic module. > The key is uploaded to the module with the presence of the holders of > co-shared secrets. To upload the key it is necessary to have the presence > of the number of secrets described in Clause 6.2.2. Uploading is done > within a closed security environment. A private key is made up of > elements. Parts of the secret key from the cards are provided in > sequence, enciphered files are uploaded into the module's memory and > then deciphered. A private key is ready to use. Uploading of the key into > the module is recorded in the register of events. > CSP s.6.2.8 Once uploaded into the module, the key shall be active. > > 6) Some of your EKU extensions are not permitted in the same > certificate. > > We are aware of it. In the SSL certificates we use only > clientAuthentication and serverAuthentication. > > 7) Note the recently announced SHA-2 requirement. SHA-1 is the only > hash specified in the CPS. 5 year certificates will not be possible. > > We are aware of it and we will start issuing certificates with SHA 256 > before this date and also supplement our CSP accordingly. > > 8) What is your OCSP response for a not issued cert? > > The answer is "unknown" - CSP s4.9.9. > > > > > > > > > > > > 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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
