o uphold community expectations.
>
>
> On Sat, Jul 4, 2020 at 10:22 AM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Thanks, Ryan.
> > I’m happy we are now in understanding to this respect.
> >
> > Then I’
Thanks, Ryan.
I’m happy we are now in understanding to this respect.
Then I’d change the literally ongoing plan. We should have the new CAs
hopefully today. Then I would do maybe also today the reissuance of the bad
ones and I’ll revoke the offending certificates during the period.
Best.
___
El viernes, 3 de julio de 2020, 18:18:49 (UTC+2), Ryan Sleevi escribió:
> Pedro's option is to reissue a certificate for that key, which as you point
> out, keeps the continuity of CA controls associated with that key within
> the scope of the audit. I believe this is the heart of Pedro's risk
> a
Ryan,
I don’t think I’m failing to see the security problem, but we evidently have
different perception of the risk level for the particular case of internal
delegation.
Anyway I will just cease in my intent and just act as it’s expected, looking as
guidance to the reaction of other CAs where p
>
> Yes. But that doesn't mean we blindly trust the CA in doing so. And that's
> the "security risk".
But the point then is that a delegated responder that had the required
"noCheck" extension wouldn't be affected by this issue and CAs wouldn't need to
react, and therefore the issue to solve i
Hello Ryan,
I’m fully understanding your argumentative line, but I’d still have a question
for you:
Does the operator of a root and it’s hierarchy have the right to delegate OCSP
responses to its own responders?
If your answer is “No”, then I don’t have anything else to say, but if your
answer
, 2 de julio de 2020, 23:33:05 (UTC+2), Ryan Sleevi escribió:
> On Thu, Jul 2, 2020 at 5:30 PM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hello Ryan,
> > Thanks for your detailed response.
> >
> > Just to
still done anyway.
Thanks,
Pedro
El jueves, 2 de julio de 2020, 22:11:52 (UTC+2), Ryan Sleevi escribió:
> On Thu, Jul 2, 2020 at 2:34 PM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hello.
> > Sorry if this question is
Hello.
Sorry if this question is incorrect, but I’d like to know if it would
acceptable that, for CAs that are owned and operated by the same entity that
the Root, the CA certificate is reissued with the same key pair without the
offending EKU, instead of doing a full issuance with new keys.
I
+1
I got the same understanding when I read this last year.
El jueves, 2 de julio de 2020, 13:38:48 (UTC+2), douglas...@gmail.com escribió:
> Ryan,
>
> Given the recent announcement "SECURITY RELEVANT FOR CAs: The curious case of
> the Dangerous Delegated Responded Cert", how does you discussio
El jueves, 2 de julio de 2020, 9:23:19 (UTC+2), Paul van Brouwershaven
escribió:
> But as Pedro also mentioned, the EKU extension in intermediate certificates
> acts as a constraint on the permitted EKU OIDs in end-entity certificates,
> which means you won't be able to use delegated OCSP signing
Sorry, my message was incomplete... please read the las part as:
Can you please clarify why this is not correct and what is the security
problem it creates if the CA is not operated externally?
El jueves, 2 de julio de 2020, 8:19:34 (UTC+2), Pedro Fuentes escribió:
> Hello,
> Our understanding
Hello,
Our understanding when creating this SubCA was that the CA certificate should
include the EKUs that would be allowed to issue, and therefore, as it would
generate certificates for the OCSP responders, it should include such EKU, the
same it would include the EKU for clientAuthentication,
As already said, this is purely about personal data processing, so the relevant
regulation applies. I don't see need for the Root Programs to deal with this,
as compliance with privacy regulations is already a requisite for Webtrust and
other audits.
In countries affected by GDPR, which is the
El domingo, 3 de mayo de 2020, 21:05:05 (UTC+2), Ryan Sleevi escribió:
> Pedro,
>
> Did you mean Section 3, not Section 4?
>
Yes, my bad... My comment was indeed related to section 3
___
dev-security-policy mailing list
dev-security-policy@lists.mozill
Hello,
this commentary it's quite obvious and probably unnecessary, but I would just
say that the controversy that section 4 of the survey is raising is simply
because many of us have the feeling that this change of certificate lifespan
should have come by means of a ballot and a new version of
Thanks, Arnold.
Our change was more complex, so we had to go to a more cumbersome process,
including audits of the ownership receiving party.
What I guess it's required now is an explicit confirmation from Mozilla to say
if such a direct transfer to an entity not member of the program is compli
Hello Arnold,
as we did recently an ownership change, I'm interested on how yours is arranged.
I'd have some questions:
- Would this imply the change of ownership of all the subordinates too or some
will remain owned by T-Systems?
- You mention that the ownership change already has a date (July,
Today, February 10th 2020, WISeKey has disclosed an incident report regarding
TLS certificate mis-issuance due to divergence in a trademark in the
Organization Field.
The public disclosure can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1614290
Pedro Fuentes
WISeKey
Today, January 15th 2020, WISeKey was made aware of possible TLS certificate
mis-issuance due to a typo in the Organization Field.
The public disclosure can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1609501
Pedro Fuentes
WISeKey
___
Dear Wayne and rest of the community,
as a follow-up of our request and the agreed plan, I'm pleased to inform you
that the OISTE Foundation had a positive "Point-in-Time" audit report, which
implies the start of separate audit track for our Roots, driven by OISTE, and
that complements the WISe
I have the feeling that this going to something over-complicated...
Let's think in a simple case, which is, I think, the most common scenario where
there's some delegation:
1. A company needs MPKI service for its employees, who use email addresses in
one or more domains owned by the company
2.
Hi Wayne,
I agree with this approach, it's quite explicit but flexible at the same time.
Thanks,
Pedro
El martes, 14 de mayo de 2019, 0:49:40 (UTC+2), Wayne Thayer escribió:
> On Mon, May 13, 2019 at 7:06 AM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozi
Piggybacking to Ryan's message and putting into my mundane words, I'd say that
is reasonable to say that a CA must not delegate the validation of what is
after the @ in the email address, but I think it's totally admissible to let
the domain owner (and typically email service provider) to assume
la/pkipolicy/commit/803ec1a1414318a69491854a867dc69889442b7b
>
> On Sat, Apr 27, 2019 at 11:36 AM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hello,
> >
> > I totally agree about the (...) be disclosed in the CPS.
&g
Hello,
my main concern about applying this would be that this would lead to forbid the
option to suspend a personal certificate.
On a side note about suspension... I was not active in the forums when this was
discussed and adopted and I'm sure there was a clear benefit on disallowing
suspension
I think this exception is only acceptable if the CA commits in its CPS on not
issuing leaf certificates from a Policy CA... And we should consider such leaf
certificates after the effective date as misissuances.
But maybe enforcing and controlling this requirement could be tricky.
Just my two c
Hello,
I totally agree about the need to specify this information clearly in the
documentation framework, but I personally think that it's not always adequate
to force listing the intermediate CA certificates in the CP, but definitely
this information is required to be disclosed in the CPS.
My
Thanks, Wayne.
I added in the bug some additional info requested by Ryan Sleevy.
Basically:
- I added an attachment with the list of certificates suffering the issue.
There are 37 certificates, of which 30 are precertificates. All are test
issuance. None of these were issued to customers, nor
Hello,
related to this... I'd like to point out something that is bugging me...
Section 7.1.5 of the BR stipulates...
First paragraph: "For a Subordinate CA Certificate to be considered Technically
Constrained..."
Second paragraph: "If the Subordinate CA Certificate includes the
id-kp-serverAu
In light of the recent discussion related to serial number Entropy, at WISeKey
we could verify that we were also affected by this issue. We are still doing
the final investigation, but I'd like to open this thread to initiate the
disclosure. I'll do the same opening a bug.
As a preliminary note
Hello Ryan,
thanks for your reply.
El lunes, 4 de marzo de 2019, 18:20:20 (UTC+1), Ryan Sleevi escribió:
>
> Just to make sure: This isn't really a question about CT at all, is it?
> It's a question about CAs performing testing in production that leads to
> misissuances.
>
Mostly is the second
El lunes, 4 de marzo de 2019, 12:37:43 (UTC+1), arnold...@t-systems.com
escribió:
> The incident report can be found here,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1530718
Hello,
related to this...
Is there a policy about test certificates and CT logs?
Sometimes it's required to do "ne
El martes, 5 de febrero de 2019, 17:03:50 (UTC+1), Ryan Sleevi escribió:
>
> Note that the topic of whether or not subscriber EKUs was significantly
> discussed in the past, and is why the policy is/tries to be very clear that
> it applies to anything technically capable of SSL/TLS issuance, and
s-pollination of keys and
> certificates).
>
> On Mon, Feb 4, 2019 at 5:38 PM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Thanks Wayne.
> >
> > Definitely, these things, the less left to interpretation, the
Thanks Wayne.
Definitely, these things, the less left to interpretation, the better... I
personally think BR should consider the fact that under a Root there can be
different certificate policies, because as you say the strict reading of BR
implies that suspension is forbidden also for certifi
Well... my understanding is that “Repository” refers there to the one of the
Issuing CA, not the whole repository under a Root, because a Root could have
subordinates that don’t issue SSL, and for which suspension could be allowed.
___
dev-security-pol
Hello,
sorry if this is a silly question, but I was wondering if it is allowed that a
Root or Intermediate CA suspends the certificate of an issuing CA.
We can imagine the case of a suspected key compromise, or even a contractual
breach, that could lead to recommend putting the Issuing CA in "qu
(Same Pedro as before...it was another account)
>
> There's nothing that specifies the cert must be issued after the verifying
> control or that issuance can't be part of the verification process. Although
> this seems backwards, I still think it's compliant with the Mozilla policy.
>
Well.. Ac
Hi Wayne,
thanks for your prompt reaction. I insert my comments below.
El jueves, 29 de noviembre de 2018, 19:01:16 (UTC+1), Wayne Thayer escribió:
> Questions for OISTE/WISeKey:
>
> Your plans for new audits will largely cover the requirement that OISTE
> demonstrate compliance with the entiret
This is a message addressed to the CA/Browser community related to the request
to transfer the ownership of the Roots currently held by WISeKey, to the OISTE
Foundation.
My name is Pedro Fuentes, Chief Security Officer at WISeKey. I’m sending you
this message as primary contact for WISeKey, as
Hi Rufus,
I got internal server error on that link, but I really appreciate your post and
the link to code!
Pedro
El miércoles, 28 de noviembre de 2018, 8:45:42 (UTC+1), Buschart, Rufus
escribió:
> To simplify the process of monitoring crt.sh, we at Siemens have implemented
> a little web serv
This is related to Mozilla Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1503638
INCIDENT REPORT:
1. How your CA first became aware of the problem
Rob Stradling contacted a person related to WISeKey CA and it was redirected to
us. Please note that the official channel for these communication
Hello,
I've a question closely related to this. I'd appreciate guidance.
I'm refactoring our CP & CPS documents considering that a CA can issue
different types of certificates, so there would be multiple CP and one CPS.
My strategy is that if the stipulation is defined in one of the document (C
Hello,
please note that if you didn't check this already, the above links only work
now from the WISeKey website. You can access to the seals from the footer at
any page at wisekey.com or you can use these direct links:
Webtrust for CA:
https://cdn.wisekey.com/uploads/images/Audit-Report-and-Ma
God rest his soul
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
SL BR:
https://www.cpacanada.ca/webtrustseal?sealid=10027
Thanks and regards,
Pedro
El martes, 26 de junio de 2018, 23:11:08 (UTC+2), Wayne Thayer escribió:
> On Tue, Jun 26, 2018 at 1:53 PM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> &
El martes, 26 de junio de 2018, 23:11:08 (UTC+2), Wayne Thayer escribió:
> On Tue, Jun 26, 2018 at 1:53 PM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi escribió:
El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi escribió:
>
> To be fair, you can align those periods by having one report prepared for 9
> May 2017 to your current audit period, and then include GC in with your
> normal audit - without having to alter your period. It allows you to
Hi Ryan,
My comments below.
El martes, 26 de junio de 2018, 21:12:44 (UTC+2), Ryan Sleevi escribió:
>
> I just want to make sure - the plan is to provide a Period of Time report
> from when the key was created to 1 year after (i.e. 9 May 2017 to 8 May
> 2018)?
> If so, that definitely closes the
.mozilla.org> wrote:
>
> > On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > 7. In my humble opinion, I think that these requirements must be formalized
> > > in audit crite
certificate between May 9, 2017 and
> September 16, 2017. Examples of considerations can be the adoption of the
> same CP/CPS, the inclusion in scope of a previous audit (for example, was
> this included in the scope of the Gen A/Gen B CAs audit for the period
> ending September 1
ibió:
> Hi Pedro,
>
> I think the previous replies tried to indicate that I will not be available
> to review your feedback at all this week.
>
> On Mon, Jun 4, 2018 at 9:18 AM, Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wr
Kind reminder.
Thanks!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Dear all,
As a reminder... WISeKey has three Roots "GA" (Generation A), GB and GC. GA and
GB are already included and covered by annual audits. GC is the new one, only
included by now by Microsoft.
I got some inputs from the auditors, that I add here:
"For the next annual audit, covering the pe
Thanks a lot, Ryan.
I see there's still an open concern, so I'll add a first comment to it.
> > > * As noted, the key generation was performed in May, and this audit is a
> > > period of time audit beginning in September. This does mean that there
> > is a
> > > gap in the audit coverage - from M
Dear all,
please find bellow our responses to the "Meh" and "Bad" issues raised by Ryan.
In respect to the points related to our auditors, we got their feedback and
we're inserting also their responses here.
Some of the points implied a change in the CPS, which is going to be published
in less t
Thanks Wayne and Ryan, your feedback always helps us to improve.
I'll respond in a separate message to Ryan concerns/questions.
Only about the audit periods... it's not easy to synchronize everything, so
what we did is the following:
- A point-in-time audit after the Root was created
- A three-m
El lunes, 14 de mayo de 2018, 23:59:07 (UTC+2), Tim Hollebeek escribió:
> As Neil correctly notes, it would be foolish to try to impose semantics and
> apply
> policy from the web CAA records onto email certificate issuance without first
> figuring out what the semantics, requirements and polici
Just to say that looking at this from Europe, I don't see this feasible.
Citizens getting their personal eIDAS-compliant certificate go through
face-to-face validation and will give virtually any valid e-mail address to
appear in their certificate.
El sábado, 12 de mayo de 2018, 2:30:58 (UTC+
60 matches
Mail list logo