KIR S.A. Root Inclusion Request

[Kathleen Wilson]

Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the �SZAFIR
ROOT CA� root certificate and enable all three trust bits.

KIR S.A. is a private corporation in Poland which currently mainly
issues qualified certificates for general public and plans to issue
non-qualified certificates (e.g. SSL certificates). KIR S.A. is an
automated clearing house in Poland and its core business is clearings,
and has built numerous business relationships within banking sector.
Therefore, KIR S.A. is aiming to expand its sales in services such as
SSL and VPN certificates. KIR S.A. has another line of products called
PayByNet, and has created a vast network of relationships within online
stores that KIR S.A. can leverage to create customer base for trusted
non-qualified certificates.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=817994

And in the pending certificates list:
http://www.mozilla.org/projects/security/certs/pending/

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8441701

Noteworthy points:

* The primary documents, the CP and CPS, are provided in both English
and Polish.

Document Repository:
http://elektronicznypodpis.pl/en/information/documents-and-agreements
CPS:
http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
CP: http://elektronicznypodpis.pl/files/doc/certification_policy.pdf

* CA Hierarchy: There is currently one internally-operated
subordinate-CA which issues 6 types of end-user certificates:
- Standard certificate - For protection of information sent
electronically, using mainly e-mail, for authorizing access to systems,
customer authentication in SSL connections. It allows signing and
encrypting data in an electronic form and authenticating subscribers.
- Code signing certificate
- VPN certificate
- SSL certificate
- Test certificate - For testing co-operation of the certificate with
solutions used or developed by a recipient of certification services or
a subscriber.
- ELIXIR certificate - For protecting information sending within ELIXIR
and EuroELIXIR systems. This kind of certificates are issued only for
Participants of ELIXIR and EuroELIXIR systems.

* The request is to enable all three trust bits.

** CPS section 3.2, Initial Identity Validation: Depending on the type
of certificate the procedure of certificate issuance may be different
and is relative to a specific certification policy.
To receive a certificate it is necessary for the subscriber who is a
natural person or an authorised representative of the recipient of
certification services to present:
1) an identification card (or its photocopy depending on the type of
certificate);
2) documents confirming rights to the domain (optionally, relative to
the certificate type);
3) a file with the certificate request (if the pair of keys is generated
individually by the subscriber).
KIR S.A. may expect presentation of other documents, in case entering
data other than the subscriber's first name and surname and the PESEL or
NIP number into the certificate is requested.

** CPS section 3.2.2: Identification and authentication of entities
other than a natural person is the case when data of such entity is
included in the data for the certificate for the issuance of which it
applies to KIR S.A., or data included in the certificate contains
information about such entity, e.g. the name of the Internet domain.
Depending on the type of certificate, identification shall be performed
on the basis of documents sent by the recipient of certification
services or data disclosed in the Agreement and in the order.
The manner of confirming such data depends on the type of certificate.
For this purpose KIR S.A. may request sending additional documents,
check the data of the recipient of certification services in commonly
accessible registers and services, obtain a card of signatures of
persons authorised to represent the recipient of certification services.
Issuance of the certificate may also require a personal meeting of a
person authorised to represent a specific entity with an authorised
representative of KIR S.A.
Wishing to authenticate other data recording which in the certificate a
specific entity requests, KIR S.A. may ask for:
1) placing data indicated by KIR S.A. in a target server by the
subscriber acting to order of a legal person, which is to verify the
rights to the Internet domain;
2) providing answer to a query sent by KIR S.A. to an e-mail address
placing of which in the certificate a legal person demands.

** CPS section 3.2.5. Checking Rights to Receive Certificate
The recipient of certification services signs an agreement with KIR S.A.
for the provision of certification services. Authorised representatives
also sign data for the certificate included in the order for a specific
subscriber. Thus, pursuant to an agreement they confirm the subscriber's
right to use the certificate in which the data of the entity they
represent is included.
The right to represent an entity by such persons is checked by KIR S.A.
in the course of identification and authentication.

** CP section 2.1, Standard certificate: These certificates may be used
for securing electronic mail and for logging into the systems or
services, authorising the subscriber during establishment of secure
connections.
In the process of issuing this type of certificates the operator KIR
S.A. shall verify the subscriber�s identity and the right to obtain such
certificate. The certificate is delivered to the subscriber most often
with a pair of keys generated on a carrier defined by the subscriber.
Data included in the certificate allows identifying the subscriber that
uses the certificate.

** CP section 2.2: Certificates for signing codes are used for
confirming authenticity and origins of binary codes. Based on the data
included in the certificate it is possible for define the author or an
entity that provides the code for a program or application.
In the process of issuing this type of certificates the operator KIR
S.A. shall verify the subscriber�s identity and the right to obtain such
certificate and shall confirm reliability of the data entered into the
certificate.

** CP section 2.4: An SSL certificate allows confirming authenticity of
www servers and setting up secure connections using SSL and TSL
protocols. A certificate may contain data of a single www server or
associated servers within a single domain.
In the process of issuing this type of certificates the operator KIR
S.A. shall verify the subscriber�s identity and its right to obtain a
certificate. The process may also include verification, whether the
server or domain are held by the recipient of certification services.

** CP section 2.5: Test certificate -- These certificates are used for
checking co-operation with the system or the subscriber�s IT solution.
In the process of issuing this type of certificates the operator KIR
S.A. shall verify the subscriber�s right to obtain such certificate. In
case, when test certificate is to serve to examine the possibility of
setting up secure connections, then process includes also verification,
if www server or domain are at the disposal of recipient of
certification services.

* EV Policy OID: Not requesting EV treatment

* Test Website: https://ssl.elektronicznypodpis.pl

* OCSP: http://ocsp.elektronicznypodpis.pl

* Audit: Annual audits are performed by Ernst&Young according to the
WebTrust CA and BR criteria. The WebTrust seal file contains two audit
statements: WebTrust CA and WebTrust BR.
https://cert.webtrust.org/SealFile?seal=1681&file=pdf

* Potentially Problematic Practices � None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from KIR S.A. to include the
�SZAFIR ROOT CA� root certificate and enable all three trust bits. At
the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

[Matt Palmer]

One thing leaps out at me immediately: these "test certificates". They
appear to be issued from the same CA as the regular certificates, but s3.2
states, "In case of test certificates they may be issued remotely *without
the necessity to verify the subscriber's identity". That seems... bad.
*Really* bad.

I'm also a little concerned about the last sentence of s4.9.9 (dealing with
OCSP responders) -- at least, I'm assuming that italics sentence in the
header of 4.9.10 isn't supposed to be a header. I don't think that being
able to take down your OCSP service for fours hours every week really
constitutes an acceptable level of service.

- Matt

On Tue, Sep 23, 2014 at 05:49:17PM -0700, Kathleen Wilson wrote:
> Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the

> “SZAFIR ROOT CA” root certificate and enable all three trust bits.

> S.A. shall verify the subscriber’s identity and the right to obtain

> such certificate. The certificate is delivered to the subscriber
> most often with a pair of keys generated on a carrier defined by the
> subscriber. Data included in the certificate allows identifying the
> subscriber that uses the certificate.
>
> ** CP section 2.2: Certificates for signing codes are used for
> confirming authenticity and origins of binary codes. Based on the
> data included in the certificate it is possible for define the
> author or an entity that provides the code for a program or
> application.
> In the process of issuing this type of certificates the operator KIR

> S.A. shall verify the subscriber’s identity and the right to obtain

> such certificate and shall confirm reliability of the data entered
> into the certificate.
>
> ** CP section 2.4: An SSL certificate allows confirming authenticity
> of www servers and setting up secure connections using SSL and TSL
> protocols. A certificate may contain data of a single www server or
> associated servers within a single domain.
> In the process of issuing this type of certificates the operator KIR

> S.A. shall verify the subscriber’s identity and its right to obtain

> a certificate. The process may also include verification, whether
> the server or domain are held by the recipient of certification
> services.
>
> ** CP section 2.5: Test certificate -- These certificates are used

> for checking co-operation with the system or the subscriber’s IT

> solution.
> In the process of issuing this type of certificates the operator KIR

> S.A. shall verify the subscriber’s right to obtain such certificate.

> In case, when test certificate is to serve to examine the
> possibility of setting up secure connections, then process includes
> also verification, if www server or domain are at the disposal of
> recipient of certification services.
>
> * EV Policy OID: Not requesting EV treatment
>
> * Test Website: https://ssl.elektronicznypodpis.pl
>
> * OCSP: http://ocsp.elektronicznypodpis.pl
>
> * Audit: Annual audits are performed by Ernst&Young according to the
> WebTrust CA and BR criteria. The WebTrust seal file contains two
> audit statements: WebTrust CA and WebTrust BR.
> https://cert.webtrust.org/SealFile?seal=1681&file=pdf
>

> * Potentially Problematic Practices – None Noted

> (http://wiki.mozilla.org/CA:Problematic_Practices)
>
> This begins the discussion of the request from KIR S.A. to include

> the “SZAFIR ROOT CA” root certificate and enable all three trust

> bits. At the conclusion of this discussion I will provide a summary
> of issues noted and action items. If there are outstanding issues,
> then an additional discussion may be needed as follow-up. If there
> are no outstanding issues, then I will recommend approval of this
> request in the bug.
>
> Kathleen
>

> --
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
I still can't see a wasp without thinking "400K 1W"
-- Derek Potter, uk.misc

[Przemyslaw Rawa]

Thank you for starting the public discussion about KIR S.A. Root Inclusion
Request. Answering your doubts:

As you can see above in the same point of CPS:

"To receive a certificate it is necessary for the subscriber who is a
natural person or an authorised
representative of the recipient of certification services to present:
1) an identification card (or its photocopy depending on the type of
certificate);
2) documents confirming rights to the domain (optionally, relative to the
certificate type);
3) a file with the certificate request (if the pair of keys is generated
individually by the subscriber)."

In case of test certificates according our CPS we can skip point 1) from
the above list. It means that we do not force subscriber to visit our RA
and show his identification card, as we do in case of another kinds of
certificates. But still all other things like agreement, order and
documents confirming rights to the domain are verified carefully. Note
that test cerificates have their own policy's distinguished identifier (s
2.5 CP).

We reserve itself the right to do a downtime of OCSP, but it doesn't mean
that we do it every week during normal working hours. What is acceptable
level of service for you? We can adjust our technical downtime for OCSP.







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.

[kircert...@gmail.com]

As you can see above in the same point of CPS:

"To receive a certificate it is necessary for the subscriber who is a natural person or an authorised
representative of the recipient of certification services to present:
1) an identification card (or its photocopy depending on the type of certificate);
2) documents confirming rights to the domain (optionally, relative to the certificate type);
3) a file with the certificate request (if the pair of keys is generated individually by the subscriber)."

In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP).

We reserve itself the right to downtime our OCSP, but it doesn't mean that we do it every week during normal working hours. What is acceptable level of service for you? We can adjust our technical downtime for OCSP.

> > * Potentially Problematic Practices - None Noted

[Matt Palmer]

On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircert...@gmail.com wrote:
> As you can see above in the same point of CPS:
>

> "To receive a certificate it is necessary for the subscriber who is a natural person or an authorised
> representative of the recipient of certification services to present:
> 1) an identification card (or its photocopy depending on the type of certificate);
> 2) documents confirming rights to the domain (optionally, relative to the certificate type);
> 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber)."
>

> In case of test certificates according our CPS we can skip point 1 from
> the above list. It means that we do not force subscriber to visit our RA
> and show his identification card, as we do in case of another kinds of
> certificates. But still all other things like agreement, order and

> documents confirming rights to the domain are verified carefully.

Rights to the domain is indicated there as being "optional", and I can't
find any indication in the CPS of which certificate types will be
domain-validated. Also, the only place I've found a description of your
domain validation practices is at the bottom of CPS s3.2.2, which only
mentions having information placed on a server. My reading of the e-mail
communication option is for purposes other than domain validation. Can you
confirm that is the case?

> Note that test cerificates have their own policy's distinguished
> identifier (s 2.5 CP).

Are you asking Mozilla to blacklist certificates marked with that OID from
being trusted? If not, the fact that they have such an identifier is
irrelevant for the purposes of determining trustworthiness.

> We reserve itself the right to downtime our OCSP, but it doesn't mean that
> we do it every week during normal working hours. What is acceptable level
> of service for you? We can adjust our technical downtime for OCSP.

100%. OCSP is a fundamental service for a publically-trusted CA to provide.
Given that it can easily be run as a read-only service for a period of time
(in your case, up to 24 hours), there is no reason why maintenance cannot be
done entirely without interruption.

- Matt

[Jeremy.Rowley]

A couple of notes:
1) Under Section 3.4 and 4.9, suspension is not permitted for SSL certs
under the BRs.
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
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.
4) Archiving is required for 7 years under the BRs (5.4.3 and 5.5).
5) 6.28 should require at least two individuals acting together to
activate the private key
6) Some of your EKU extensions are not permitted in the same certificate.
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.
8) What is your OCSP response for a not issued cert?

Jeremy

On 9/24/2014 6:17 AM, kircert...@gmail.com wrote:
> As you can see above in the same point of CPS:
>

> "To receive a certificate it is necessary for the subscriber who is a natural person or an authorised
> representative of the recipient of certification services to present:
> 1) an identification card (or its photocopy depending on the type of certificate);
> 2) documents confirming rights to the domain (optionally, relative to the certificate type);
> 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber)."
>

> In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP).

>
> We reserve itself the right to downtime our OCSP, but it doesn't mean that we do it every week during normal working hours. What is acceptable level of service for you? We can adjust our technical downtime for OCSP.
>
>

> On Wednesday, September 24, 2014 6:02:15 AM UTC+2, Matt Palmer wrote:

>>> * Potentially Problematic Practices - None Noted

>>> (http://wiki.mozilla.org/CA:Problematic_Practices)
>>> This begins the discussion of the request from KIR S.A. to include
>>> the "SZAFIR ROOT CA" root certificate and enable all three trust
>>> bits. At the conclusion of this discussion I will provide a summary
>>> of issues noted and action items. If there are outstanding issues,
>>> then an additional discussion may be needed as follow-up. If there
>>> are no outstanding issues, then I will recommend approval of this
>>> request in the bug.
>>> Kathleen
>>> --
>>> dev-security-policy mailing list
>>> dev-secur...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>>
>> --
>>
>> I still can't see a wasp without thinking "400K 1W"
>>
>> -- Derek Potter, uk.misc

> _______________________________________________

> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

> .
>

[Kurt Roeckx]

On 2014-09-24 14:17, kircert...@gmail.com wrote:
> We reserve itself the right to downtime our OCSP, but it doesn't mean that we do it every week during normal working hours. What is acceptable level of service for you? We can adjust our technical downtime for OCSP.

The BR has this in 13.2.2:
The CA SHALL maintain an online 24x7 Repository that application
software can use to automatically check the current status of all
unexpired Certificates issued by the CA.

I don't think that scheduled downtime is acceptable. Guaranteeing 100%
availability might not be possible, but I think you should aim for that.


Kurt

[Certificates]

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.

[Certificates]

Answers for Matt Palmer questions:

On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircert...@gmail.com wrote:
> As you can see above in the same point of CPS:
>
> "To receive a certificate it is necessary for the subscriber who is a
natural person or an authorised
> representative of the recipient of certification services to present:
> 1) an identification card (or its photocopy depending on the type of
certificate);
> 2) documents confirming rights to the domain (optionally, relative to
the certificate type);
> 3) a file with the certificate request (if the pair of keys is generated
individually by the subscriber)."
>
> In case of test certificates according our CPS we can skip point 1 from
> the above list. It means that we do not force subscriber to visit our
RA
> and show his identification card, as we do in case of another kinds of
> certificates. But still all other things like agreement, order and
> documents confirming rights to the domain are verified carefully.

Rights to the domain is indicated there as being "optional", and I can't
find any indication in the CPS of which certificate types will be
domain-validated. Also, the only place I've found a description of your
domain validation practices is at the bottom of CPS s3.2.2, which only
mentions having information placed on a server. My reading of the e-mail
communication option is for purposes other than domain validation. Can
you
confirm that is the case?

CSP s3.2 concerns all type of certificates. "Optional, relevant to the
certificate type" means that we don't ask for domain validation for e.g.
the standard certificate. We do domain validation for all SSL certifcates.
More details about process of validation during issuing certificates of
all types you can find in CP.

> Note that test cerificates have their own policy's distinguished
> identifier (s 2.5 CP).

Are you asking Mozilla to blacklist certificates marked with that OID from
being trusted? If not, the fact that they have such an identifier is
irrelevant for the purposes of determining trustworthiness.

I am not sure if Mozilla has implemented funcionality like blacklist for
certificates marked with OID. As we can see other CAs do not force their
subscriber to show their ID even during issuing non-test certificates. We
check subscribers identity face to face. Only issuing test cerificate we
don't ask subscriber for visiting our RA. Below you can find one example
from CPS of CA which root certificates is inclued in the Mozilla browser:
"Registration might require subscriber or a representative authorized by
the subscriber to personally attend a
registration authority. Nevertheless, CERTUM permits (for specified
certificate types) sending applications for
registration by mail, electronic mail, WWW sites, etc.; examination of the
applications does not necessitate a
physical contact with the requester."

> We reserve itself the right to downtime our OCSP, but it doesn't mean
that
> we do it every week during normal working hours. What is acceptable
level
> of service for you? We can adjust our technical downtime for OCSP.

100%. OCSP is a fundamental service for a publically-trusted CA to
provide.
Given that it can easily be run as a read-only service for a period of
time
(in your case, up to 24 hours), there is no reason why maintenance cannot
be
done entirely without interruption.

We maintain OCSP on line 24x7. But 100% availability of is utopia. Even e-
banking systems have their downtimes. We want to be fair to the user,
that's why we inform them about possibility of downtime. We can remove
this 4 hour from CSP.

[Jeremy.Rowley]

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.

> 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.
>
>

[Matt Palmer]

I don't read the CP (specifically, s2.4) as confirming "that the Applicant
controls the Fully-Qualified Domain Name" (as per BR 1.1.9 s.9.2.1).

> > Note that test cerificates have their own policy's distinguished
> > identifier (s 2.5 CP).
>
> Are you asking Mozilla to blacklist certificates marked with that OID from
> being trusted? If not, the fact that they have such an identifier is
> irrelevant for the purposes of determining trustworthiness.
>
> I am not sure if Mozilla has implemented funcionality like blacklist for
> certificates marked with OID. As we can see other CAs do not force their
> subscriber to show their ID even during issuing non-test certificates. We
> check subscribers identity face to face.

That is not clear from the CPS.

> > We reserve itself the right to downtime our OCSP, but it doesn't mean
> that
> > we do it every week during normal working hours. What is acceptable
> level
> > of service for you? We can adjust our technical downtime for OCSP.
>
> 100%. OCSP is a fundamental service for a publically-trusted CA to
> provide.
> Given that it can easily be run as a read-only service for a period of
> time
> (in your case, up to 24 hours), there is no reason why maintenance cannot
> be
> done entirely without interruption.
>
> We maintain OCSP on line 24x7. But 100% availability of is utopia. Even e-
> banking systems have their downtimes.

My bank doesn't go down for four hours every week, nor does it claim to be
able to. If it did, I'd find another bank, but as a relying party, I can't
find another CA to present a certificate for a site I wish to verify the
authenticity of.

> We want to be fair to the user,
> that's why we inform them about possibility of downtime. We can remove
> this 4 hour from CSP.

I think that would be best.

- Matt

[fhw...@gmail.com]

‎With proper planning, redundant equipment, and so forth, the perceived outage can be zero (that means 100% availability). Keep in mind you have 2 sets of customers: the people who purchase your service and the people who rely on your judgment as to who should or should not be trusted.

Notifying your clients that the OCSP responders will be offline for 4 hours is the equivalent of your clients telling their customers: "don't visit my website for the next 4 hours because my cert issuer won't verify that I'm trustworthy". Or perhaps: "I'm going to send you an email but you can't read it for the next 4 hours because you won't be able to validate it with my CA".

In so many words, a better plan needs to be put in place.

[Certificates]

Answers for Matt Palmer questions:

I don't read the CP (specifically, s2.4) as confirming "that the Applicant
controls the Fully-Qualified Domain Name" (as per BR 1.1.9 s.9.2.1).

KIR's answer:

To get a SSL certificate client has to provide(CSP s.3.2):

-agreement,
-order,
-document confirming rights to the domain .

Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4):

1. verification of agreement (we check if the company exist, who sign
agreement, if it is entitled representative),
2. verification of order (we check who sign order, if it is entitled
representative, if the data given in order are correct),
3. verification whether the client has granted the right to the domain (we
check who is an owner of the domain);
4. verification whether the client controls the domain (we ask to place
data indicated by KIR on server);
5. identity of person authorised to represent client (we meet face to face
with that person).

If it is still unclear in CSP we can make it more clarified.

> > Note that test cerificates have their own policy's distinguished
> > identifier (s 2.5 CP).
>
> Are you asking Mozilla to blacklist certificates marked with that OID
from
> being trusted? If not, the fact that they have such an identifier is
> irrelevant for the purposes of determining trustworthiness.
>
> I am not sure if Mozilla has implemented funcionality like blacklist for

> certificates marked with OID. As we can see other CAs do not force their

> subscriber to show their ID even during issuing non-test certificates.
We
> check subscribers identity face to face.

That is not clear from the CPS.

KIR's answer:

When issuing test certificate, we check the points 1 -4 listed above, and
the validy of the renewed certifcate.

Best regards
Przemyslaw Rawa

My bank doesn't go down for four hours every week, nor does it claim to be
able to. If it did, I'd find another bank, but as a relying party, I
can't
find another CA to present a certificate for a site I wish to verify the
authenticity of.

> We want to be fair to the user,
> that's why we inform them about possibility of downtime. We can remove
> this 4 hour from CSP.

I think that would be best.

- Matt

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
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.

[Certificates]

Answer for questions about OCSP downtime:

We maintain OCSP on line 24x7. We will remove this 4 hours from CSP.

Regards

Przemyslaw Rawa

Od: fhw...@gmail.com
Do: dev-secur...@lists.mozilla.org,
Data: 2014-09-26 01:23
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

‎With proper planning, redundant equipment, and so forth, the perceived
outage can be zero (that means 100% availability). Keep in mind you have 2
sets of customers: the people who purchase your service and the people who
rely on your judgment as to who should or should not be trusted.

Notifying your clients that the OCSP responders will be offline for 4
hours is the equivalent of your clients telling their customers: "don't
visit my website for the next 4 hours because my cert issuer won't verify
that I'm trustworthy". Or perhaps: "I'm going to send you an email but you
can't read it for the next 4 hours because you won't be able to validate
it with my CA".

In so many words, a better plan needs to be put in place.

From: Matt Palmer
Sent: Thursday, September 25, 2014 3:37 PM‎

[Przemyslaw Rawa]

Answer for suspension and OCSP issues (Robin Alden and Jeremy Rowley):

RFC 5280 allows suspension. In our opinion, suspension is a usefull tool
for PKI. If you get an information that something goes wrong with the
certificate, but you need time to confirm it. In such situation we suspend
certificate and start to verify the information at once. If the
information was true, we revoke certificate, but if it was a fake we turn
the certificate into valid status. Of course you can say that we should
revoke certificate at once, but what if the information we get from user
wasn't true? SSL server will be seen as untrusted. What if the information
is true, but we spent one hour to confirm this. During this one hour user
trust the server but he shouldn't.
What's more RFC 2560 also mentions about suspension (s 2.2):

The "good" state indicates a positive response to the status inquiry.
At a minimum, this positive response indicates that the certificate
is not revoked, but does not necessarily mean that the certificate
was ever issued or that the time at which the response was produced
is within the certificate's validity interval. Response extensions
may be used to convey additional information on assertions made by
the responder regarding the status of the certificate such as
positive statement about issuance, validity, etc.

The "revoked" state indicates that the certificate has been revoked
(either permanently or temporarily (on hold)).

The "unknown" state indicates that the responder doesn't know about
the certificate being requested.

After changing suspended certificate status to valid, information about
such certificate is removed from CRL, so the OCSP answer after
unsuspension will be 'valid". It looks that BR goes further than RFC.

Preparing to Mozilla Root Inclusion Program we looked at others CA, which
certificates are included as trusted by Mozilla. Please note that there
are CAs on Mozilla trusted list which have suspension and unsuspension
services, e.g.:
http://certum.pl/servlet/pl.id.sys.servlets.FileDownloadServlet?filename=/upload_module/downloads/dokuments/CCK-DK02-ZK02_CPS_v3_8.pdf
, http://cybertrust.omniroot.com/repository/Cybertrust_CPS_v_5_6.pdf,
https://www.buypass.com/support/download-center/_attachment/27671?_ts=1439fc82a60

Unizeto

4.9.15.
Certification Authority certificate suspension requires formal request of
the Security
Inspector, confirmed by Chief of CERTUM.
The procedure for suspending a subscriber's certificate is the same as in
the case of
revocation of the certificate (see .4.9.3.1). Upon successful verification
of the suspension request
the Cerification Authority changes status of certificate and publishes it
on the list of revoked
certificates (the reason is certificateHold).
Only the CERTUM operator is authorized to unsuspend a certificate.
Unsuspension can
only be issued if CERTUM has information justifying certificate
unsuspension


CyberTrust

http://cybertrust.omniroot.com/repository/Cybertrust_CPS_v_5_6.pdf
Revocation and suspension requests can also be placed directly to the
Cybertrust RA at the
correspondence address listed at the beginning of this CPS or at
EVServ...@verizonbusiness.com.
Upon request from an RA, the Cybertrust CA revokes a digital certificate
if:
· There has been loss, theft, modification, unauthorized disclosure, or
other compromise of
the private key of the certificate’s subject.
· The certificate’s subject or their appointed subscriber has breached a
material obligation
under this CPS.
· The performance of a person’s obligations under this CPS is delayed or
prevented by a
natural disaster, computer or communications failure, or other cause
beyond the person's
reasonable control, and as a result, another person’s information is
materially threatened
or compromised.
· There has been a modification of the information contained in the
certificate of the
certificate’s subject.
The Cybertrust RA requests the revocation of a certificate promptly upon
verifying the identity of the
requesting party. Verification of the identity can be done through
information elements featured in the
identification data that the subscriber has submitted to the Cybertrust
RA. Upon request by a
Cybertrust RA, the Cybertrust CA takes prompt action to revoke the
certificate.
Cybertrust does not provide suspension services directly to subscribers.
Cybertrust is allowed to
suspend a certificate for up to 7 calendar days if subscriber does not
fulfil its obligations including
financial compensation. Subscriber will be informed of a suspension and
its reasons.
For SureServer EV certificates, revocation shall be mandatory when the
Cybertrust CA determines, in
its sole discretion that the certificate was not issued in accordance with
the terms and conditions of
the EV guidelines.
4.8.1 Term and Termination of Suspension and Revocation
Suspension may last for a maximum of seven calendar days to establish the
conditions that caused
the request of suspension.
The Cybertrust CA publishes notices of suspended or revoked certificates
in the Cybertrust CA
repository. The Cybertrust CA may publish its suspended or revoked
certificates in its CRL and
additionally, by any other means as it sees fit.

BUYPASS

4.4.5 Circumstances for suspension
a) If an RA is not able to process a Certificate revocation request in due
time (see 4.4 b), the Certificate SHALL be suspended until the revocation
request has been properly processed.

b) If a Certificate has been suspended as a result of a), the Certificate
SHALL either be revoked or unsuspended once the revocation request has
been properly processed.
4.4.8 Limits on suspension period
a) A Certificate that has been suspended SHALL be revoked or unsuspended
at the latest 30 days after the Certificate was suspended.

For a suspended Certificate, the original Certificate revocation request
is processed in due time to ensure that the Certificate is either revoked
or unsuspended at the latest 30 days after the Certificate was suspended.

7. The OCSP profile SHALL conform to the specifications contained in RFC
2560 [16].


Regards
Przemyslaw Rawa

[Jeremy Rowley]

Certificate suspension is permitted for client certs but not SSL. See https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/j4pS8H8P5Go/-PJRIoKgf04J

[Jeremy Rowley]

I think you should clarify what constitutes a "document confirming rights to the domain". Is this authorization from the registrar or registrant? Who provides the document?

My bank doesn't go down for four hours every week, nor does it claim to be able to. If it did, I'd find another bank, but as a relying party, I can't find another CA to present a certificate for a site I wish to verify the authenticity of.

> We want to be fair to the user,
> that's why we inform them about possibility of downtime. We can remove
> this 4 hour from CSP.

I think that would be best.

- Matt

[Matt Palmer]

On Fri, Sep 26, 2014 at 03:31:20PM +0200, Przemyslaw Rawa wrote:
> Preparing to Mozilla Root Inclusion Program we looked at others CA, which
> certificates are included as trusted by Mozilla. Please note that there
> are CAs on Mozilla trusted list which have suspension and unsuspension
> services

That's an argument for having those CA's inclusion reviewed; it isn't an
argument to allow the inclusion of KiR's root.

- Matt

[Matt Palmer]

On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote:
> I don't read the CP (specifically, s2.4) as confirming "that the Applicant
> controls the Fully-Qualified Domain Name" (as per BR 1.1.9 s.9.2.1).
>
> KIR's answer:
>
> To get a SSL certificate client has to provide(CSP s.3.2):

That's presumably supposed to be "CPS", not "CSP" (I noted that error
frequently throughout the documents themselves; you might want to get that
corrected).

> -agreement,
> -order,
> -document confirming rights to the domain .

What valid forms can this document take? What steps are taken to verify or
validate that information?

> Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4):
>
> 1. verification of agreement (we check if the company exist, who sign
> agreement, if it is entitled representative),
> 2. verification of order (we check who sign order, if it is entitled
> representative, if the data given in order are correct),
> 3. verification whether the client has granted the right to the domain (we
> check who is an owner of the domain);

How is that ownership check performed?

> 4. verification whether the client controls the domain (we ask to place
> data indicated by KIR on server);
> 5. identity of person authorised to represent client (we meet face to face
> with that person).
>
> If it is still unclear in CSP we can make it more clarified.

That would be appreciated.

> > > Note that test cerificates have their own policy's distinguished
> > > identifier (s 2.5 CP).
> >
> > Are you asking Mozilla to blacklist certificates marked with that OID
> from
> > being trusted? If not, the fact that they have such an identifier is
> > irrelevant for the purposes of determining trustworthiness.
> >
> > I am not sure if Mozilla has implemented funcionality like blacklist for
>
> > certificates marked with OID. As we can see other CAs do not force their
>
> > subscriber to show their ID even during issuing non-test certificates.
> We
> > check subscribers identity face to face.
>
> That is not clear from the CPS.
>
> KIR's answer:
>
> When issuing test certificate, we check the points 1 -4 listed above, and
> the validy of the renewed certifcate.

That would be a good clarification to place in the CPS itself.

- Matt

[Certificates]

Ok. Thank you for your hint. We decided to resign from suspension of SSL
certificates. We will provide appropriate changes in our Certificate
Practice Statement.

Od: Jeremy Rowley <jeremy...@digicert.com>
Do: Przemyslaw Rawa <Przemys...@kir.com.pl>,
"dev-secur...@lists.mozilla.org"
<dev-secur...@lists.mozilla.org>,
Data: 2014-09-26 16:15
Temat: RE: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

Certificate suspension is permitted for client certs but not SSL. See
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/j4pS8H8P5Go/-PJRIoKgf04J

-----Original Message-----
From: dev-security-policy [
mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org

Preparing to Mozilla Root Inclusion Program we looked at others CA, which
certificates are included as trusted by Mozilla. Please note that there
are CAs on Mozilla trusted list which have suspension and unsuspension

[Certificates]

We decided to resign from suspension of SSL certificates. We will provide
appropriate changes in our Certificate Practice Statement.

Od: Matt Palmer <mpa...@hezmatt.org>
Do: dev-secur...@lists.mozilla.org,

Data: 2014-09-26 22:40
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

On Fri, Sep 26, 2014 at 03:31:20PM +0200, Przemyslaw Rawa wrote:

> Preparing to Mozilla Root Inclusion Program we looked at others CA,
which
> certificates are included as trusted by Mozilla. Please note that there
> are CAs on Mozilla trusted list which have suspension and unsuspension

> services

That's an argument for having those CA's inclusion reviewed; it isn't an
argument to allow the inclusion of KiR's root.

- Matt

[Certificates]

On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote:
> I don't read the CP (specifically, s2.4) as confirming "that the
Applicant
> controls the Fully-Qualified Domain Name" (as per BR 1.1.9 s.9.2.1).
>
> KIR's answer:
>
> To get a SSL certificate client has to provide(CSP s.3.2):

That's presumably supposed to be "CPS", not "CSP" (I noted that error
frequently throughout the documents themselves; you might want to get that
corrected).

KIR's answer:

OK, we'll check it.

> -agreement,
> -order,
> -document confirming rights to the domain .

What valid forms can this document take? What steps are taken to verify
or
validate that information?

KIR's answer:

1. Verification of agreement is done by checking if the company exist or
not. We check it at the public registers, for example for companies
registered in Poland we check it in register provide by Polish Ministry of
Justice and Central Registration and Information of Business(
https://ems.ms.gov.pl/krs/wyszukiwaniepodmiotu?t:lb=t,
https://prod.ceidg.gov.pl/CEIDG/CEIDG.Public.UI/Search.aspx). Based on
this information we checked if the person who sign agreement and order is
entitled representative (if the company is in the register, there are also
information who is entitled representative).
2. To verify an order we do validation in the same way as for the
agreement and also we check if the data given in order are correct, e.g.
if the data given in the order concerns the company which signed the
agreement.

> Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4):
>
> 1. verification of agreement (we check if the company exist, who sign
> agreement, if it is entitled representative),
> 2. verification of order (we check who sign order, if it is entitled
> representative, if the data given in order are correct),
> 3. verification whether the client has granted the right to the domain
(we
> check who is an owner of the domain);

How is that ownership check performed?

KIR's answer:
For the domain name specified in the order we check at
http://www.dns.pl/cgi-bin/whois.pl whether the data presented to the
domain owner are the same as customer data and the data for the
certificate indicated in the order and agreement. If they are the same
operator asks the administrator of the domain to place unique
identification code supplied by KIR on the server. If the code is placed
correctly KIR's operator confirms that order is valid and lets to issue
certificate. He also makes a note in our internal system about how he
checked validity of the ownership of the given domain.

> 4. verification whether the client controls the domain (we ask to place
> data indicated by KIR on server);
> 5. identity of person authorised to represent client (we meet face to
face
> with that person).
>
> If it is still unclear in CSP we can make it more clarified.

That would be appreciated.

KIR's answer:
OK

> > > Note that test cerificates have their own policy's distinguished
> > > identifier (s 2.5 CP).
> >
> > Are you asking Mozilla to blacklist certificates marked with that OID
> from
> > being trusted? If not, the fact that they have such an identifier is
> > irrelevant for the purposes of determining trustworthiness.
> >
> > I am not sure if Mozilla has implemented funcionality like blacklist
for
>
> > certificates marked with OID. As we can see other CAs do not force
their
>
> > subscriber to show their ID even during issuing non-test certificates.

> We
> > check subscribers identity face to face.
>
> That is not clear from the CPS.
>
> KIR's answer:
>
> When issuing test certificate, we check the points 1 -4 listed above,
and
> the validy of the renewed certifcate.

That would be a good clarification to place in the CPS itself.

KIR's answer:
OK

- Matt

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Od: Matt Palmer <mpa...@hezmatt.org>
Do: dev-secur...@lists.mozilla.org,
Data: 2014-09-26 22:45
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

[Certificates]

For the domain name specified in the order we check at
http://www.dns.pl/cgi-bin/whois.pl whether the data presented to the
domain owner are the same as customer data and the data for the
certificate indicated in the order and agreement. If they are the same
operator asks the administrator of the domain to place unique
identification code supplied by KIR on the server. If the code is placed
correctly KIR's operator confirms that order is valid and lets to issue
certificate. He also makes a note in our internal system about how he
checked validity of the ownership of the given domain.

Od: Jeremy Rowley <jeremy...@digicert.com>
Do: Certificates <certif...@kir.com.pl>,
"dev-secur...@lists.mozilla.org"
<dev-secur...@lists.mozilla.org>,

Data: 2014-09-26 16:16
Temat: RE: KIR S.A. Root Inclusion Request



I think you should clarify what constitutes a "document confirming rights
to the domain". Is this authorization from the registrar or registrant?
Who provides the document?

-----Original Message-----
From: dev-security-policy [
mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org

] On Behalf Of Certificates
Sent: Friday, September 26, 2014 6:42 AM
To: dev-secur...@lists.mozilla.org
Subject: Re: KIR S.A. Root Inclusion Request

Answers for Matt Palmer questions:

I don't read the CP (specifically, s2.4) as confirming "that the Applicant
controls the Fully-Qualified Domain Name" (as per BR 1.1.9 s.9.2.1).

KIR's answer:

To get a SSL certificate client has to provide(CSP s.3.2):

-agreement,
-order,
-document confirming rights to the domain .

Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4):

1. verification of agreement (we check if the company exist, who sign
agreement, if it is entitled representative), 2. verification of order (we
check who sign order, if it is entitled representative, if the data given
in order are correct), 3. verification whether the client has granted the

right to the domain (we check who is an owner of the domain); 4.

verification whether the client controls the domain (we ask to place data
indicated by KIR on server); 5. identity of person authorised to represent
client (we meet face to face with that person).

If it is still unclear in CSP we can make it more clarified.

> > Note that test cerificates have their own policy's distinguished
> > identifier (s 2.5 CP).
>
> Are you asking Mozilla to blacklist certificates marked with that OID
from
> being trusted? If not, the fact that they have such an identifier is
> irrelevant for the purposes of determining trustworthiness.
>
> I am not sure if Mozilla has implemented funcionality like blacklist
> for

> certificates marked with OID. As we can see other CAs do not force
> their

> subscriber to show their ID even during issuing non-test certificates.
We
> check subscribers identity face to face.

That is not clear from the CPS.

KIR's answer:

When issuing test certificate, we check the points 1 -4 listed above, and
the validy of the renewed certifcate.

Best regards
Przemyslaw Rawa

Od: Matt Palmer <mpa...@hezmatt.org>
Do: dev-secur...@lists.mozilla.org,
Data: 2014-09-25 22:38
Temat: Re: KIR S.A. Root Inclusion Request Wysłane przez:
"dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

I don't read the CP (specifically, s2.4) as confirming "that the Applicant
controls the Fully-Qualified Domain Name" (as per BR 1.1.9 s.9.2.1).

> > Note that test cerificates have their own policy's distinguished
> > identifier (s 2.5 CP).
>
> Are you asking Mozilla to blacklist certificates marked with that OID
from
> being trusted? If not, the fact that they have such an identifier is
> irrelevant for the purposes of determining trustworthiness.
>
> I am not sure if Mozilla has implemented funcionality like blacklist
> for

> certificates marked with OID. As we can see other CAs do not force
> their

> subscriber to show their ID even during issuing non-test certificates.
We
> check subscribers identity face to face.

That is not clear from the CPS.

[Matt Palmer]

On Mon, Sep 29, 2014 at 03:41:07PM +0200, Certificates wrote:
> On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote:

> > -agreement,
> > -order,
> > -document confirming rights to the domain .
>

> What valid forms can this document take? What steps are taken to verify
> or
> validate that information?
>
> KIR's answer:

All of this additional information should be placed in the CPS.

- Matt

[Certificates]

We are able to add some additional information to our CPS. In our opinion
they should be more general than those in our explanations sent to you.
More detailed information are placed in our internal procedures, which are
checked by auditors.

Od: Matt Palmer <mpa...@hezmatt.org>
Do: dev-secur...@lists.mozilla.org,
Data: 2014-09-29 21:35
Temat: Re: ODP: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

[Matt Palmer]

On Tue, Sep 30, 2014 at 01:17:22PM +0200, Certificates wrote:
> We are able to add some additional information to our CPS. In our opinion
> they should be more general than those in our explanations sent to you.
> More detailed information are placed in our internal procedures, which are
> checked by auditors.

Frankly, I don't have a particularly high opinion of the quality of the job
that auditors do on CAs. The CPS is a Certification *Practice* Statement,
not a Certification *Principles* Statement, and so I think it is reasonable
to expect a description of the practices undertaken in issuing certificates.
If you believe otherwise, and you're right, then the rest of the members of
this list will presumably be in support your application and you'll be
accepted into the trust store.

- Matt

[Kathleen Wilson]

On 9/30/14, 1:40 PM, Matt Palmer wrote:
> The CPS is a Certification *Practice* Statement,
> not a Certification *Principles* Statement, and so I think it is reasonable
> to expect a description of the practices undertaken in issuing certificates.

Matt is correct.

BR section 8.2.1 says: "The CA SHALL develop, implement, enforce, and
annually update a Certificate Policy and/or Certification Practice
Statement that describes in detail how the CA implements the latest
version of these Requirements."

https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
"The CA's CP/CPS must include a reasonable description of the ways the
CA can verify that the certificate subscriber owns/controls the domain
name(s) to be included in the certificate."

The more information in the CP/CPS, the better.

Kathleen

[Certificates]

We agree with and do what BR section 8.2.1 says.
We agree also with sentence that "...it is reasonable to expect a
description of the practices undertaken in issuing certificates". As we
wrote before we will do it in more detailed way. Maybe it will not be the
same sentences we used in our internal procedures and answer sent to Matt
Palmer. As we checked in other CPs and CPSs they are more general in those
sections. Even they are similar to our current CP and CPS. But if Mozilla
representative claimed it's not clear enough we wolud change it
immediately together with others issues which were metioned during this
discussion.
We value efforts made by our auditors. We think they did their job
properly with a lot of days analysing our procedures and practices.

Regards

Przemyslaw

Od: Kathleen Wilson <kwi...@mozilla.com>
Do: mozilla-dev-s...@lists.mozilla.org,
Data: 2014-10-01 00:42
Temat: Re: ODP: Re: ODP: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

On 9/30/14, 1:40 PM, Matt Palmer wrote:

> The CPS is a Certification *Practice* Statement,
> not a Certification *Principles* Statement, and so I think it is
reasonable
> to expect a description of the practices undertaken in issuing
certificates.

Matt is correct.

BR section 8.2.1 says: "The CA SHALL develop, implement, enforce, and
annually update a Certificate Policy and/or Certification Practice
Statement that describes in detail how the CA implements the latest
version of these Requirements."

https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
"The CA's CP/CPS must include a reasonable description of the ways the
CA can verify that the certificate subscriber owns/controls the domain
name(s) to be included in the certificate."

The more information in the CP/CPS, the better.

Kathleen

[Kathleen Wilson]

Dear Przemyslaw,

So we can all understand, please send us the actual changes that you
plan to make to the CP/CPS in order to address the concerns that were
raised so far in this discussion. Or, attach a draft version of the
proposed new CP/CPS to the bug.

Thanks,
Kathleen

> 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.

[Erwann Abalea]

Le jeudi 2 octobre 2014 11:19:24 UTC+2, Certificates a écrit :
[...]

> We value efforts made by our auditors. We think they did their job
> properly with a lot of days analysing our procedures and practices.

There's more and more examples of the contrary, unfortunately.

The "SZAFIR Trusted CA" CA has at least 2 different certificates:
- https://bugzilla.mozilla.org/attachment.cgi?id=8454356
- https://bugzilla.mozilla.org/attachment.cgi?id=8454357
Both of these certificates have the same name, ergo they belong to the same CA.
Yet, 2 different and incompatible CRLs from the same issuer exist:
- http://www.elektronicznypodpis.pl/crl/trusted_ca_2013.crl
- http://www.elektronicznypodpis.pl/crl/trusted_ca.crl

The CRLNumber numbering has been restarted from 1, and the revoked certificates list is different. This is a security problem, and is non compliant to X.509 and RFC5280. An attacker can replace one CRL by another, it will be accepted by a compliant application. This is similar to the PKITS test 4.4.19 (Valid Separate Certificate and CRL Keys Test19).

The same problem exists with one of your CAs listed in the official Polish TSL to issue Qualified Certificates, the CA is named "C=PL, O=Krajowa Izba Rozliczeniowa S.A., CN=COPE SZAFIR - Kwalifikowany, serialNumber=Nr wpisu: 6", and there's 3 different certificates for the same CA, and 3 different and incoherent CRLs. I guess you have been ETSI TS101456 audited (that's necessary to deliver Qualified Certificates), and the auditor didn't notify this. This problem dates back to 2011, at least.

[Kurt Roeckx]

On 2014-10-02 18:53, Erwann Abalea wrote:
> Yet, 2 different and incompatible CRLs from the same issuer exist:

[...]

> The CRLNumber numbering has been restarted from 1, and the revoked certificates list is different. This is a security problem, and is non compliant to X.509 and RFC5280. An attacker can replace one CRL by another, it will be accepted by a compliant application. This is similar to the PKITS test 4.4.19 (Valid Separate Certificate and CRL Keys Test19).

At least godaddy is doing this too, they have over 100 CRLs covering the
same CA that don't contain the same revoked serial numbers each having
it's own counter, each still updated. The certificates point to 1 of them.


Kurt

[Certificates]

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

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. 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.

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.

Regards

Przemyslaw

Od: Erwann Abalea <eab...@gmail.com>
Do: mozilla-dev-s...@lists.mozilla.org,
Data: 2014-10-02 18:54
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

Le jeudi 2 octobre 2014 11:19:24 UTC+2, Certificates a écrit :
[...]

> We value efforts made by our auditors. We think they did their job
> properly with a lot of days analysing our procedures and practices.

There's more and more examples of the contrary, unfortunately.

The "SZAFIR Trusted CA" CA has at least 2 different certificates:
- https://bugzilla.mozilla.org/attachment.cgi?id=8454356
- https://bugzilla.mozilla.org/attachment.cgi?id=8454357
Both of these certificates have the same name, ergo they belong to the
same CA.

Yet, 2 different and incompatible CRLs from the same issuer exist:

- http://www.elektronicznypodpis.pl/crl/trusted_ca_2013.crl
- http://www.elektronicznypodpis.pl/crl/trusted_ca.crl

The CRLNumber numbering has been restarted from 1, and the revoked
certificates list is different. This is a security problem, and is non
compliant to X.509 and RFC5280. An attacker can replace one CRL by
another, it will be accepted by a compliant application. This is similar
to the PKITS test 4.4.19 (Valid Separate Certificate and CRL Keys Test19).

The same problem exists with one of your CAs listed in the official Polish
TSL to issue Qualified Certificates, the CA is named "C=PL, O=Krajowa Izba
Rozliczeniowa S.A., CN=COPE SZAFIR - Kwalifikowany, serialNumber=Nr wpisu:
6", and there's 3 different certificates for the same CA, and 3 different
and incoherent CRLs. I guess you have been ETSI TS101456 audited (that's
necessary to deliver Qualified Certificates), and the auditor didn't
notify this. This problem dates back to 2011, at least.

[Certificates]

Ok, we're working on it.

Od: Kathleen Wilson <kwi...@mozilla.com>
Do: mozilla-dev-s...@lists.mozilla.org,
Data: 2014-10-02 17:55
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

Dear Przemyslaw,

So we can all understand, please send us the actual changes that you
plan to make to the CP/CPS in order to address the concerns that were
raised so far in this discussion. Or, attach a draft version of the
proposed new CP/CPS to the bug.

Thanks,
Kathleen


On 10/2/14, 2:18 AM, Certificates wrote:

[Erwann Abalea]

For GoDaddy, the CRLs are limited in their scope, each of these CRLs has a critical IssuingDistributionPoint extension. That way, nobody can replace

[Jeremy.Rowley]

Right - you can parse CRLs into deltas as long as they include an IDP.

Jeremy

[Erwann Abalea]

Sorry, left hand kicked the tab key, don't remember what the right hand did but it sent the mail... Continuing it.

For GoDaddy, the CRLs are limited in their scope, each of these CRLs has a critical IssuingDistributionPoint extension. That way, nobody can replace "gds2-17.crl" with "gds2-18.crl", because the RP will have to check that the CRLDP extension in the certificate matches with the IDP extension in the CRL.

There's nothing similar here for SZAKIR. The 2 CRLs are full scope CRLs from the same issuer, with 2 different contents.

[Erwann Abalea]

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.

[Certificates]

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 <eab...@gmail.com>
Do: mozilla-dev-s...@lists.mozilla.org,
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.c...@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.

[Erwann Abalea]

Bonsoir,

Le lundi 6 octobre 2014 15:55:24 UTC+2, Certificates a écrit :
> 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.

Please read X.509 or RFC5280 again. AKI is not a way to limit the scope of the CRL. AKI is not to be set as a critical extension. AKI is only a helper so the RP can avoid guessing which key signed this object. The RP has absolutely no obligation to follow this helper.
The ONLY RFC5280-compatible extension to reduce the scope of a CRL is the IssuingDistributionPoint.

GoDaddy distinguishes the CRLs not by their AKI, but by the IssuingDistributionPoint extension, and this extension MUST be critical for its goal to be achieved. BTW, the AKI extension of such partitioned CRLs at GoDaddy is identical on all the CRLs (I checked http://crl.godaddy.com/gds2-{1,...,17}.crl).

[siuda...@gmail.com]

Erwann,
I agree that AKI is not a way to limit scope of CRL.
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).
We have to also remember that AKI must be included in CRL, use od IDP is optional.

[Certificates]

We studied RFC5280 and we look into it once again. As you notice GoDaddy
issues 17 different CRLs signed all with one certificate and the same pair
of keys. It’s a little bit different situation than we have.
It looks that Mozilla and Internet Explorer deal properly with our CRLs
without IDP extension. While you want to connect with our test web page
https://revoked.elektronicznypodpis.pl/ , which has a revoked certificate
you get an error: sec_error_revoked_certificate. IE also finds our
certificate as revoked. For Mozilla OCSP is priority as it is mentioned in
BR, so I’m not sure that IDP is absolutely needed in our CRLs.

Regards

Od: Erwann Abalea <eab...@gmail.com>
Do: mozilla-dev-s...@lists.mozilla.org,
Data: 2014-10-07 00:20
Temat: Re: Re: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>

Bonsoir,

Le lundi 6 octobre 2014 15:55:24 UTC+2, Certificates a écrit :
> 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.

Please read X.509 or RFC5280 again. AKI is not a way to limit the scope of
the CRL. AKI is not to be set as a critical extension. AKI is only a
helper so the RP can avoid guessing which key signed this object. The RP
has absolutely no obligation to follow this helper.
The ONLY RFC5280-compatible extension to reduce the scope of a CRL is the
IssuingDistributionPoint.

GoDaddy distinguishes the CRLs not by their AKI, but by the
IssuingDistributionPoint extension, and this extension MUST be critical
for its goal to be achieved. BTW, the AKI extension of such partitioned
CRLs at GoDaddy is identical on all the CRLs (I checked
http://crl.godaddy.com/gds2-{1,...,17}.crl).

[Erwann Abalea]

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.

[siuda...@gmail.com]

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.

[Kurt Roeckx]

On 2014-10-09 13:55, siuda...@gmail.com wrote:
> 4. Lets consider OCSP - all responders uses CRL as backbone. What we have in OCSP request? AKI. IDP is completely useless.

Please note that only using information from the CRL is not good enough.
See the CA/B baseline requirements in 13.2.6. You also need to know
which serial numbers have been issued.


Kurt

[siuda...@gmail.com]

of course :) (serial number, issuerKeyHash, IssuerNameHash).

[Erwann Abalea]

Le jeudi 9 octobre 2014 13:55:00 UTC+2, siuda...@gmail.com a écrit :
> W dniu czwartek, 9 października 2014 02:12:47 UTC+2 użytkownik Erwann Abalea napisał:

> 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 do you mean by "[it] doesn't support AKI in CRL"?

If what you have in mind is "it doesn't use the AKI to find the correct CA certificate/public key to validate the CRL with", then yes it does, or it wouldn't have been able to validate the second case.

If what you have in mind is "it doesn't compare the AKI contained in the CRL with the AKI contained in the certificate it tries to validate", then no. No because this is NOT what is required by the standard (or you wouldn't be able to have separate keys for cert and CRL signing).

You admitted earlier that AKI does not limit the scope of the CRL, so each of the CRLs is a full-scope and complete CRL for the entire "SubCA" CA, covering ALL the certificates issued under "generation1" AND "generation2" certificates.

If OpenSSL/NSS/CAPI/whatever does not support a critical IDP, that's their problem (and therefore becomes your problem also as a CA). But your interpretation of how a CRL should be validated cannot be imposed to everybody.

I modified the test-case to include IDP in the CRLs.
Grab the files https://kouettland.com/SZAFIR2/test.eml, https://kouettland.com/SZAFIR2/verifier1.cacrt, https://kouettland.com/SZAFIR2/verifier2.cacrt
Run the same commands, OpenSSL now correctly fails to validate the second case: "Verify error:Different CRL scope". That answers your question.

> 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 ?

"cms" tool has been extensively modified to be able to run the NIST PKITS (I derived the test 4.4.19 to produce this one). Obviously, since in the first case it correctly finds the certificate as revoked, this revocation check is done.

> 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.

I just provided a test-case that validates correctly under OpenSSL with a security risk. Should I also build specific test-cases for NSS and CAPI? And include IDP for completeness?

> Moreover, browsers also doesnt have any problem with correct validation KIR certs and CRL

Did you try negative tests as this one? Your inclusion request asks for all 3 trust bits, not only TLS.

> 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.

You misread the bug ticket. I provided a patch to "mod_ssl" to enhance its own CRL validation in case of a CA renew. The final solution has been to use OpenSSL's CRL validation mechanism, which is complete.

> So - rfc5280 says one thing, market revised it and uses AKI, and only AKI.

???? (les bras m'en tombent)

> 4. Lets consider OCSP - all responders uses CRL as backbone. What we have in OCSP request? AKI. IDP is completely useless.

OCSP responders in light of CABR BR can't use CRL as backbone.
RFC2560/6960 doesn't say which one of issuerKeyHash/issuerNameHash is to be used to find the certificate status.
IDP is not necessary in OCSP, that's irrelevant.

> 5. RFC5280, 6.3 CRL validation -read it..- conforming implementations that support CRL are not required to implement this algorithm...

The correct section is:
"Conforming implementations that support CRLs
are not required to implement this algorithm, but they MUST be
functionally equivalent to the external behavior resulting from this
procedure when processing CRLs that are issued in conformance with
this profile. Any algorithm may be used by a particular
implementation so long as it derives the correct result."

This is more or less taken from X.509, which provides another algorithm. The final results are identical whatever the algorithm chosen (except if you renew your Root CA certificate).

> 6. I respect standards, but they should serve the market,not in opposite way.

That's your view.

You're discussing to avoid performing your duties as a CA, you're considering that a renew of your CA certificate constitutes an entirely different CA, contrary to the standard, with expected security consequences for end-users.

You have 2 solutions:
- include a critical IDP in your CRLs to limit their scope, or
- continue to produce full-scope CRLs and make sure that the CRLs produced by "SZAFIR Trusted CA"-2011 AND "SZAFIR Trusted CA"-2014 contain the same revocation information; that is, they both MUST revoke the certificates produced by "SZAFIR Trusted CA"-2011+2014, and take the CRLNumber from the same sequence.

[Kathleen Wilson]

On 9/23/14 5:49 PM, Kathleen Wilson wrote:
> Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the “SZAFIR
> ROOT CA” root certificate and enable all three trust bits.
>


Thanks to all of you who have contributed to this discussion.

To summarize the discussion so far, KIR has action items to update their
CPS and CRLs.

Action Item #1: Update CPS to:
A) Clarify steps to confirm the certificate subscriber owns/controls the
domain name to be included in the certificate.
B) Clarify that the same domain control verification is required for SSL
Test Certificates. Or, a preferable solution would be that test
certificates are not issued in this CA hierarchy.
C) Remove the text allowing for 4 hour OCSP downtime
D) Don’t allow certificate suspension for SSL certs
E) Clarify the maximum allowed validity for SSL certs. If it is up to 5
years, then add re-verificatin at least every 39 months, and note that
after April 1, 2015 the BRs no longer allow for 5 year certs.
F) Clarify that archiving is required for 7 years.
G) Clarify that in SSL certificates the EKU can only have
clientAuthentication and serverAuthentication.
H) Clarify plans regarding SHA-1

Action item #2: Update CRL according to one of the following options.

- include a critical IDP in your CRLs to limit their scope, or
- continue to produce full-scope CRLs and make sure that the CRLs
produced by "SZAFIR Trusted CA"-2011 AND "SZAFIR Trusted CA"-2014
contain the same revocation information; that is, they both MUST revoke
the certificates produced by "SZAFIR Trusted CA"-2011+2014, and take the
CRLNumber from the same sequence.

Did I miss anything?

Are there any further questions or comments for KIR before they update
their CPS?

Thanks,
Kathleen

[Kathleen Wilson]

Thanks again to all of you who contributed to this discussion.

I am now closing this discussion, and I will track the action items in
the bug. Any further follow-up should be added directly to the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=817994

When I have confirmed completion of the action items, I will start a new
discussion thread.

Thanks,
Kathleen