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
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
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
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
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> wrote:
>
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
Kind reminder.
Thanks!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
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
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
; 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 15, 2017?), or other documentary evidence
rg> 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 criteria or exp
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 escrib
God rest his soul
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
:
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:
>
> > E
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:
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
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
(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..
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
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
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
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
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
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
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
s 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 better... I
> &g
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
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.
___
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
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
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
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.mozilla.o
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.
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
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.
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
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
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,
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
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
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
+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
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
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.
be 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
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
, 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 be sure that we are
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
>
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.
ity 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’d change the li
>
> 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
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
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
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
58 matches
Mail list logo
