If you look under Section 13.2.4, a CA cannot remove an entry from its
CRLs, meaning there is no way to un-suspend a certificate.
On 9/25/2014 7:03 AM, Certificates wrote:
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
.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy