Thanks for good overview.
I'd like to add some more.
Actually the most questionalble part of the chain is so called Supervisory
bodies.
Of course, root programs do not rely on SB assessment, but under eIDAS they are
authorised to audit TSPs and then publish National trust lists (as Scheme
Hi Wayne,
This is how its supposed to work under eIDAS:
1. Check the value of the QCStatement [1] of the certificate under
problem (which is the location of PDS);
2. Open the PDS and check relevant contact info as in [2].
Thanks,
M.D.
[1] see 4.3.4 (QCStatement regarding location of PKI Disc
Thank you for clarification.
Do you think the terms "/approval scheme/", "/supervision scheme/",
"/accreditation//scheme/" etc. (used in some ETSI TSs or the Commission
Decisions) have the same meaning and ETSI EN 319 403 is just one of
possible "/certification scheme/s"?
Thanks,
M.D.
On 11
You might want to add one more:
REGULATION (EC) No 765/2008 OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 9 July 2008 setting out the requirements for accreditation
and market surveillance relating to the marketing of products and
repealing Regulation (EEC) No 339/93
see also eIDAS recit
FYI:
see section 7.4.4 of ETSI EN 319 403, Electronic Signatures and
Infrastructures (ESI); Trust Service Provider Conformity Assessment -
Requirements for conformity assessment bodies assessing Trust Service
Providers,
http://www.etsi.org/deliver/etsi_en/319400_319499/319403/02.02.02_60/en_3
Hi Gerv,
FYI: ETSI TS 119 612 V2.2.1 (2016-04), Electronic Signatures and
Infrastructures (ESI); Trusted Lists
http://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.02.01_60/ts_119612v020201p.pdf
Thanks,
M.D.
On 6/26/2017 4:50 PM, Gervase Markham via dev-security-policy wrote:
A few ro
+1
Thanks,
M.D.
On 6/5/2017 7:16 PM, Ryan Sleevi via dev-security-policy wrote:
On Mon, Jun 5, 2017 at 11:52 AM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Has there ever been an effort by the root programs to directly assess
monetary penalties to
The updated CP/CPS are now under internal review and will be published
before end of February.
Thanks,
M.D.
On 2/8/2016 8:00 PM, Kathleen Wilson wrote:
On 2/7/16 2:53 AM, winpackja...@gmail.com wrote:
And how much more time is this going to take? Since no issues have
been highlighted...
W
eIDAS is becoming the only common Law on e-signatures (for the EU) and
I'm not aware of any regulation on mandatory CP/CPS structures.
Thanks,
M.D.
On 10/22/2015 8:56 PM, Richard Barnes wrote:
On Thu, Oct 22, 2015 at 1:42 PM, Kathleen Wilson
wrote:
All,
In section 2.2 of version 1.3 of th
On 9/11/2015 3:23 AM, Peter Bowen wrote:
On Thu, Sep 10, 2015 at 3:54 PM, Peter Kurrasch wrote:
It seems to me that the benefits of this proposed change are minimal while
the negative impacts to embedded systems are significant. Perhaps I've
missed something?
It should be understood that cod
Thank you for your comments.
Let me start with your questions first.
RS-Q1:
"From interpreting Section 3.1.1, it would appear that a TLS server
certificate (e.g. DVCP, OVCP, EVCP, EVCP+) will never have a commonName
field appear within the subject, as the commonName is expressly
identified a
On 9/1/2015 3:56 AM, Ryan Sleevi wrote:
On Mon, August 31, 2015 5:48 pm, Moudrick M. Dadashov wrote:
I'm afraid there seems to be a bit misinterpretation of ETSI policies:
EVCP, EVCP+, DVCP, OVCP are based on the same general requirements and
have cumulative effect: higher level
I'm afraid there seems to be a bit misinterpretation of ETSI policies:
EVCP, EVCP+, DVCP, OVCP are based on the same general requirements and
have cumulative effect: higher level (e.g. EVCP) conformance assessment
assumes lower level conformence while the opposite is not true.
In other words i
Thank you, we too consider general policy related discussions separate
from specific Root inclusion applications.
As for email trust bit enabled Roots, isn't TB another popular product
from Mozilla? However I'm not sure if NSS currently stores any "code
signing only" roots.
Thanks,
M.D.
On
Dear Ryan,
thank you for your constructive criticism, suggestions and recommendations.
This is just a short confirmation that we are working on the feedback
which we expect to post in a couple of days.
All the best,
M.D.
On 8/29/2015 4:16 AM, Ryan Sleevi wrote:
On Wed, July 29, 2015 1:34 pm
Its hard not to agree with you.
>At the most basic level, it's not clear to me >to whom this legislation is
>directed. Is it >citizens within the EU?
This is funniest part of the game, in fact member states supposed to maintain
their TSLs but to my best knowledge, there is no obligation to
+1
Thanks,
M.D.
On 7/7/2015 4:02 AM, Peter Bowen wrote:
Thinking about this from a technical perspective, rather than a
political one, this seems very similar to a user deciding to add
additional certificates to their trust store. I think the primary
differences are the need to add a set of ce
Peter, a while back a well known [bank industry] supervisor here has
stated: "ethics and moral are not of dimensions this world".
So, how about a more realistic scenario where TeliaSonera buys whatever
foreign legislation needed for its baby CA in Estonia?
Since our 3 years discussion on this
creation of an Issuing CA (s), p. 8, 9 and 10 of the Root inclusion
policy apply.
Would it be sufficient?
Thanks,
M.D.
On 4/24/2015 7:19 PM, Ryan Sleevi wrote:
On Fri, April 24, 2015 8:39 am, Moudrick M. Dadashov wrote:
So I thought everybody "standing under the umbrella" is tr
On 4/24/2015 5:30 PM, Ryan Sleevi wrote:
On Fri, April 24, 2015 6:34 am, Moudrick M. Dadashov wrote:
Kathleen, wouldn't be it easier to apply the transferred CA the same
requirements as to any other? That means the new CA must have its
operations audited under its ***fully comp
Kathleen, wouldn't be it easier to apply the transferred CA the same
requirements as to any other? That means the new CA must have its
operations audited under its ***fully completed transfer*** operations.
The root and all associated intermediates must pass audit against
***then applicable***
I think what you are saying is exactly how it works for ETSI audits.
Baseline requirements are part of ETSI TS 102 042 audit:
"The present document provides guidance on the assessment of
Certification Authorities issuing Certificates primarily for use with
Transport Layer Security (TLS) proto
On 10/31/2014 1:04 PM, Anne van Kesteren wrote:
On Fri, Oct 31, 2014 at 11:22 AM, Moudrick M. Dadashov wrote:
The document below proposes a generic syntax for unique identification of
natural/legal Subjects (see Section 5):
http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN_319412-1v006-cert
On 10/31/2014 11:20 AM, Anne van Kesteren wrote:
On Wed, Oct 29, 2014 at 10:02 PM, Dean Coclin wrote:
But many people do in fact look at the security indicators. If that statement
were true, why do fraudsters bother to get SSL certs (mostly DV) for their
phishing websites?
Given that "Orga
"Having these identifiers takes us a long way towards our goal of
deterministic evaluation of certificate issuance policy — that said not
all CAs have adopted them which is technically alright since the
Baseline Requirements do allow them to use their own Policy
Identifiers". This is what Ryan
Eddy, do you mean SSL client authentication? We too rely on this a lot.
Thanks,
M.D.
On 5/20/2014 11:45 PM, Eddy Nigg wrote:
On 05/19/2014 07:40 PM, Rick Andrews wrote:
Kathleen, that means we'll be disclosing a number of intermediates
used to sign certificates that are not used for SSL, Code
Hi Rob, thanks, good news for us :)
M.D.
On 5/13/2014 11:52 PM, Rob Stradling wrote:
On 13/05/14 21:41, Moudrick M. Dadashov wrote:
"1. All new intermediate certificates that include the EKU extension
and will be used for SSL certificate issuance, must include the
id-kp-serve
On 5/13/2014 8:46 PM, Kathleen Wilson wrote:
On 5/13/14, 8:46 AM, Jeremy Rowley wrote:
That actually clears things up. Intermediate certs aren't required to
have
an EKU but, if they do and the intermediate will be used for SSL,
they must
have the id-kp-serverAuth (1.3.6.1.5.5.7.3.1) EKU.
On 5/13/2014 6:26 PM, Jeremy Rowley wrote:
During the CAB Forum discussion on this issue, someone brought up that
Qualified Certs in the EU are supposed to have either the anyEKU present or
omit the EKU. I think the post originated from Chema Gonzalez, but I'll let
him confirm. I'm not sure the
On 4/9/2014 2:04 PM, Rob Stradling wrote:
On 09/04/14 11:57, Moudrick M. Dadashov wrote:
Comodo operate intermediate CAs for several of our partners in a
similar fashion. The partner is named in the intermediate
certificate's Subject organizationName, but it is Comodo who control
On 4/9/2014 1:25 PM, Rob Stradling wrote:
On 09/04/14 00:27, Kurt Roeckx wrote:
The first example, Gandi, does sign certificates for other
organizations.
Hi Kurt.
You seem to be assuming that the Subject organizationName in the
intermediate CA certificate ("O=GANDI SAS" in this case) identi
On 10/17/2013 1:04 PM, Gervase Markham wrote:
On 17/10/13 00:07, Phillip Hallam-Baker wrote:
Each HSM vendor has their own security controls but a FIPS140 level 4
device won't release them except to another FIPS-140 device. There is no
way to extract the key from the system unencrypted.
Phil: w
32 matches
Mail list logo
