On 10/22/14, 4:02 PM, Kathleen Wilson wrote:
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 summar
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 item
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
W dniu czwartek, 9 października 2014 15:00:50 UTC+2 użytkownik Kurt Roeckx
napisał:
> On 2014-10-09 13:55, siudara...@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
On 2014-10-09 13:55, siudara...@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.
W dniu czwartek, 9 października 2014 02:12:47 UTC+2 użytkownik Erwann Abalea
napisał:
> Bonsoir,
>
>
>
> Le mardi 7 octobre 2014 13:20:48 UTC+2, siuda...@gmail.com a écrit :
>
> > W dniu wtorek, 7 października 2014 00:19:39 UTC+2 użytkownik Erwann Abalea
> > napisał:
>
>
>
> > I agree that
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 valida
that IDP is absolutely needed in our CRLs.
Regards
Od: Erwann Abalea
Do: mozilla-dev-security-pol...@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"
Bonsoir,
Le lundi 6 octobre 2014 15:5
W dniu wtorek, 7 października 2014 00:19:39 UTC+2 użytkownik Erwann Abalea
napisał:
> 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 i
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
certificate will be available tomorrow.
Regards,
Przemek
Od: Erwann Abalea
Do: mozilla-dev-security-pol...@lists.mozilla.org,
Data: 2014-10-03 20:19
Temat: Re: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
Le vendredi 3 octobre 2014 15:2
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
> add
Sorry, left hand kicked the tab key, don't remember what the right hand did but
it sent the mail... Continuing it.
Le vendredi 3 octobre 2014 19:27:06 UTC+2, Erwann Abalea a écrit :
> Le vendredi 3 octobre 2014 10:22:06 UTC+2, Kurt Roeckx a écrit :
> > On 2014-10-02 18:53, Erwann Abalea wrote:
>
Right - you can parse CRLs into deltas as long as they include an IDP.
Jeremy
On 10/3/2014 11:26 AM, Erwann Abalea wrote:
> >The CRLNumber numbering has been restarted from 1, and the revoked certifica
___
dev-security-policy mailing list
dev-securi
Le vendredi 3 octobre 2014 10:22:06 UTC+2, Kurt Roeckx a écrit :
> 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 diffe
Ok, we're working on it.
Od: Kathleen Wilson
Do: mozilla-dev-security-pol...@lists.mozilla.org,
Data: 2014-10-02 17:55
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
Dear Przemyslaw,
So we can all understand, please send us the
s.mozilla.org,
Data: 2014-10-02 18:54
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
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
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 attac
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" C
sts.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"
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 th
Data: 2014-10-01 00:42
Temat: Re: ODP: Re: ODP: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
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
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 SHAL
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
> check
@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"
On Mon, Sep 29, 2014 at 03:41:07PM +0200, Certificates wrote:
> On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote:
> > -ag
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 th
omain.
Od: Jeremy Rowley
Do: Certificates ,
"dev-security-policy@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 th
ertificate, 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-security-policy@l
We decided to resign from suspension of SSL certificates. We will provide
appropriate changes in our Certificate Practice Statement.
Od: Matt Palmer
Do: dev-security-policy@lists.mozilla.org,
Data: 2014-09-26 22:40
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: &quo
Temat: RE: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
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:
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'
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
> servic
y=digicert@lists.mozilla.org]
On Behalf Of Certificates
Sent: Friday, September 26, 2014 6:42 AM
To: dev-security-policy@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 App
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=digicert@lists.mozilla.org
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-security-policy@lists.mozilla.org,
Data: 2014-09-26 01:23
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez
and
the validy of the renewed certifcate.
Best regards
Przemyslaw Rawa
Od: Matt Palmer
Do: dev-security-policy@lists.mozilla.org,
Data: 2014-09-25 22:38
Temat: Re: KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
On Thu, Sep 25, 2014 at 03:06:5
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 you
On Thu, Sep 25, 2014 at 03:06:59PM +0200, Certificates wrote:
> Answers for Matt Palmer questions:
>
> On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@gmail.com wrote:
> > As you can see above in the same point of CPS:
> >
> > "To receive a certificate it is necessary for the subscriber
If you look under Section 13.2.4, a CA cannot remove an entry from its
CRLs, meaning there is no way to un-suspend a certificate.
On 9/25/2014 7:03 AM, Certificates wrote:
Answers for Jeremy Rowley questions:
A couple of notes:
1) Under Section 3.4 and 4.9, suspension is not permitted for SSL
ked certificate's validity period.
Regards
Robin Alden
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+robin=comodo@lists.mozilla.org] On Behalf Of Certificates
> Sent: 25 September 2014 14:03
> To: dev-security-policy@lists.mozilla
Answer for Kurt Roeckx questions:
On 2014-09-24 14:17, kircertifica...@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
Answers for Matt Palmer questions:
On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@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 recipi
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.
On 2014-09-24 14:17, kircertifica...@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
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 t
On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@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 p
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
certifi
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.
*Rea
47 matches
Mail list logo
