Re: Certinomis Issues

[Wayne Thayer via dev-security-policy]

On Thu, May 9, 2019 at 8:56 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/05/2019 02:22, Wayne Thayer wrote:
> > Thank you for this response Francois. I have added it to the issues list
> > [1]. Because the response is not structures the same as the issues list,
> I
> > did not attempt to associate parts of the response with specific issues.
> I
> > added the complete response to the bottom of the page.
> >
> > On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> ...
> > ...
>  >
> > In response to the email from Franck that you mention, Gerv responded [1]
> > by quoting the plan he had approved and stating "This seems to be very
> > different to the plan you implemented." By cross-signing Startcom's old
> > roots, Certinomis did assist Startcom in circumventing the remediation
> > plan, and by proposing one plan then implementing a different one,
> > Certinomis did so without Mozilla's consent.
> >
>
> As can be seen from your [3] link, Certinomis cross-signed StartCom's
> NEW supposedly remediated 2017 hierarchy, not the old root.
>
> Thank you for correcting me Jakob. I was confused by a statement in the
2017 thread that I referenced, but I see now that Certinomis only
cross-signed Startcom's new roots. Since Certinomis cross-signed Startcom's
new roots before the remediation plan was completed, I believe the
statements I made are otherwise correct.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certinomis Issues

[Jakob Bohm via dev-security-policy]

On 10/05/2019 02:22, Wayne Thayer wrote:

Thank you for this response Francois. I have added it to the issues list
[1]. Because the response is not structures the same as the issues list, I
did not attempt to associate parts of the response with specific issues. I
added the complete response to the bottom of the page.

On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


...

...

>

In response to the email from Franck that you mention, Gerv responded [1]
by quoting the plan he had approved and stating "This seems to be very
different to the plan you implemented." By cross-signing Startcom's old
roots, Certinomis did assist Startcom in circumventing the remediation
plan, and by proposing one plan then implementing a different one,
Certinomis did so without Mozilla's consent.



As can be seen from your [3] link, Certinomis cross-signed StartCom's
NEW supposedly remediated 2017 hierarchy, not the old root.

However it was still wrong.


Startcom misissued a number of certificates (e.g. [3]) under that
cross-signing relationship that Certinomis is responsible for as the
Mozilla program member.

By cross-signing Startcom's roots, Certinomis also took responsibility for
Startcom's qualified audit.

I will also add this information to the issues list.

- Wayne

[1] https://wiki.mozilla.org/CA/Certinomis_Issues
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ
[3] https://crt.sh/?opt=cablint=160150786




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

[Jakob Bohm via dev-security-policy]

On 10/05/2019 05:25, Ryan Sleevi wrote:

On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 09/05/2019 16:35, Ryan Sleevi wrote:

Given that the remark is that such a desire is common, perhaps you can
provide some external references documenting how one might go about
configuring such a set-up, particularly in the context of TLS trust?
Similarly, I'm not aware of any system that supports binding S/MIME
identities to a particularly CA (effectively, CA pinning) - perhaps you

can

provide documentation and reference for systems that perform this?

Thanks for helping me understand how this 'common' scenario is actually
implemented, especially given that the underlying codebases do not

support

such distinctions.



My description is based on readily available information from the
following sources, that you should also have access to:



It looks like your links to external references may have gotten stripped,
as I didn't happen to receive any.

As it relates to the topic at hand, the system you described is simply that
of internal CAs, and does not demonstrate a need to use publicly trusted
CAs. Further, going back to your previous message, to which I was replying
to make sure I did not misunderstand, given that you stated it was common,
it seemed we established that such scenarios in that message, and further
expanded upon in this, already have the capability for enterprise
management.

I wanted to make sure I did my best to understand, so that we can have
productive engagement on substance, specifically around whether there is a
technical necessity for the use of non-Root CAs to be capable of issuance
under multiple different trust purposes. It does not seem as if there's
been any external references to establish a technical necessity, so it does
not seem like the policy needs to be modified, based on the available
evidence.



There were no links, only descriptions of obvious facts that you 
willfully ignore in an effort to troll the community.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

[Ryan Sleevi via dev-security-policy]

On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 09/05/2019 16:35, Ryan Sleevi wrote:
> > Given that the remark is that such a desire is common, perhaps you can
> > provide some external references documenting how one might go about
> > configuring such a set-up, particularly in the context of TLS trust?
> > Similarly, I'm not aware of any system that supports binding S/MIME
> > identities to a particularly CA (effectively, CA pinning) - perhaps you
> can
> > provide documentation and reference for systems that perform this?
> >
> > Thanks for helping me understand how this 'common' scenario is actually
> > implemented, especially given that the underlying codebases do not
> support
> > such distinctions.
> >
>
> My description is based on readily available information from the
> following sources, that you should also have access to:
>

It looks like your links to external references may have gotten stripped,
as I didn't happen to receive any.

As it relates to the topic at hand, the system you described is simply that
of internal CAs, and does not demonstrate a need to use publicly trusted
CAs. Further, going back to your previous message, to which I was replying
to make sure I did not misunderstand, given that you stated it was common,
it seemed we established that such scenarios in that message, and further
expanded upon in this, already have the capability for enterprise
management.

I wanted to make sure I did my best to understand, so that we can have
productive engagement on substance, specifically around whether there is a
technical necessity for the use of non-Root CAs to be capable of issuance
under multiple different trust purposes. It does not seem as if there's
been any external references to establish a technical necessity, so it does
not seem like the policy needs to be modified, based on the available
evidence.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

[Jakob Bohm via dev-security-policy]

On 09/05/2019 16:35, Ryan Sleevi wrote:
> On Wed, May 8, 2019 at 10:36 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> [ Note, I am arguing a neutral position on the specific proposal ]
>>
>> The common purpose of having an internally secured (managed or on-site)
>> CA in a public hierarchy is to have end certificates which are
>> simultaneously:
>>
> 
> Despite my years of close experience with the implementation and details of
> the certificate verification engines within Google Chrome and Android,
> Mozilla Firefox, Apple iOS and macOS, and Microsoft Windows, including
> extensive work with Enterprise PKIs, I must admit, I have never heard of
> the scenario you're describing or actually being supported.
> 
> Given that the remark is that such a desire is common, perhaps you can
> provide some external references documenting how one might go about
> configuring such a set-up, particularly in the context of TLS trust?
> Similarly, I'm not aware of any system that supports binding S/MIME
> identities to a particularly CA (effectively, CA pinning) - perhaps you can
> provide documentation and reference for systems that perform this?
> 
> Thanks for helping me understand how this 'common' scenario is actually
> implemented, especially given that the underlying codebases do not support
> such distinctions.
> 

My description is based on readily available information from the 
following sources, that you should also have access to:

1. The high level documentation and feature lists for enterprise PKI 
  suites (which are completely different from the software suites 
  designed for running public CA companies, because templates, 
  validation methods and policies tend to be completely different).

2. The user and configuration interfaces for common software that needs 
  to hold certificates (web servers, mail clients etc.).  Those tend to 
  be harder to use if different relying parties need different 
  certificates for the same certificate subject.

  For example it is difficult to make mail clients sign/encrypt all 
  mails if you need different personal certificates for the same e-mail 
  account depending on who the mail is sent to, while a setting to do 
  the same thing every time is typically a builtin option.  Now imagine 
  the certificate and private key being embedded in an employee ID card,
  while company workstations don't have unlocked spare ports for 
  plugging in two different card readers (one for the employee ID card 
  containing the access certificate that keeps the machine logged in, 
  another for a USB token from a public CA).

   Similarly, it can get very tricky to make a web server use different 
  certificate settings for different visitor categories accessing the 
  same DNS name.

3. The details of publicly trusted company SubCAs that emerge from time 
  to time in compliance cases.  The details revealed tend to only make 
  sense in setups like the ones described.

4. The actual number of companies needing this is an unknown that I 
  make no claims about, it's not my proposal.

5. Maybe look at how Google employees and internal servers used 
  certificates before the formation of GTS as a public CA.  I doubt 
  all your internal operational certificates chained to your publicly 
  trusted SubCAs, and I doubt that Google sensitive systems accepted 
  purported "Google authorized" certificates issued by the 3rd party 
  public CA that signed Google's SubCA.
   [ I am not asking you to reveal the information, just think about 
  it when considering the needs of companies that are never going to 
  become root program members ].




Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CAA record checking issue

[Jeremy Rowley via dev-security-policy]

FYI, we posted this today:

 

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

 

Basically we discovered an issue with our CAA record checking system. If the
system timed out, we would treat the failure as a DNS failure instead of an
internal failure. Per the BRs Section 3.2.2:

"CAs are permitted to treat a record lookup failure as permission to issue
if: 

. the failure is outside the CA's infrastructure; 

. the lookup has been retried at least once; and 

. the domain's zone does not have a DNSSEC validation chain to the ICANN
root"

 

The failure was not outside our infrastructure so issuance was improper. 

 

We checked all the applicable CAA records and found 16 where the CAA record
would not permit us to issue if we were issuing a new cert today. What we
are proposing is to revoke these certificates and reissue them (if they pass
all the proper checks). The rest would pass if we issued today so we were
going to leave these where they are while disclosing them to the Mozilla
community. 

 

Other suggestions are welcome. 

 

The issue was put into the code back when CAA record checking became
mandatory (Sept 2017).  We generally have a peer review of our code so that
at least one other developer has looked at the system before release. In
this case, neither PM nor a second reviewer was involved in the development.
We've since implemented more stringent development processes, including
ensuring a PM reviews and brings questions about projects to the compliance
team. 

 

Anyway, let me know what questions, comments, etc you have.

 

Thanks!

Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Reported Digicert key compromise but not revoked

[Jeremy Rowley via dev-security-policy]

No argument from me there. We generally act on them no matter what.
Typically any email sent to supp...@digicert.com requesting revocation is
forwarded to rev...@digicert.com. That's the standard procedure. This one
was missed unfortunately.

-Original Message-
From: dev-security-policy  On
Behalf Of Daniel Marschall via dev-security-policy
Sent: Thursday, May 9, 2019 4:16 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Reported Digicert key compromise but not revoked

I personally do think that it matters to this forum. A CA - no matter what
kind of certificates it issues - must take revocation requests seriously and
act immediately, even if the email is sent to the wrong address. If an
employee at the help desk is unable to forward revocation requests, or needs
several weeks to reply, then there is something not correct with the CA, no
matter if the revocation request is related to a web certificate or code
signing certificate. That's my opinion on this case.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certinomis Issues

[Wayne Thayer via dev-security-policy]

Thank you for this response Francois. I have added it to the issues list
[1]. Because the response is not structures the same as the issues list, I
did not attempt to associate parts of the response with specific issues. I
added the complete response to the bottom of the page.

On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I don’t want to finish this answer without going back to the A issue, the
> Startcom cross-sign.
> I will not repeat all the history, Franck LEROY had detailed it in his
> e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of
> view: at no time did we in this case violate an existing rule, nor did we
> assist or seek to assist Startcom in circumventing the remediation plan
> proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand
> if what we wanted to do was acceptable, we clearly made it a condition for
> Iñigo to follow the plan and waited to be convinced that he had done so,
> and when, after all these precautions, we were told that we had not
> understood this remedial plan, we revoked both CAs without discussion.
> I hadn’t heard anything about it in those two years.
> So what is the factual criticism that is being made now, two years later?
> I don’t know about that.
> And what is the link with our difficulties of this year? None!
>
>
In response to the email from Franck that you mention, Gerv responded [1]
by quoting the plan he had approved and stating "This seems to be very
different to the plan you implemented." By cross-signing Startcom's old
roots, Certinomis did assist Startcom in circumventing the remediation
plan, and by proposing one plan then implementing a different one,
Certinomis did so without Mozilla's consent.

Startcom misissued a number of certificates (e.g. [3]) under that
cross-signing relationship that Certinomis is responsible for as the
Mozilla program member.

By cross-signing Startcom's roots, Certinomis also took responsibility for
Startcom's qualified audit.

I will also add this information to the issues list.

- Wayne

[1] https://wiki.mozilla.org/CA/Certinomis_Issues
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/lyAX9Wz_AQAJ
[3] https://crt.sh/?opt=cablint=160150786
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Reported Digicert key compromise but not revoked

[Jeremy Rowley via dev-security-policy]

Thanks Wayne. We’ll update our CPS to keep it clear.

 

From: Wayne Thayer  
Sent: Thursday, May 9, 2019 5:04 PM
To: Andrew Ayer 
Cc: Jeremy Rowley ; Jeremy Rowley via 
dev-security-policy 
Subject: Re: Reported Digicert key compromise but not revoked

 

DigiCert CPS section 1.5.2 [1] could also more clearly state that 
rev...@digicert.com   is the correct address for 
'reporting suspected Private Key Compromise, Certificate misuse, or other types 
of fraud, compromise, misuse, inappropriate conduct, or any other matter 
related to Certificates.' Since both email addresses are listed in that 
section, it's not difficult to mistake supp...@digicert.com 
  as the problem reporting mechanism, even though 
the last sentence in 1.5.2.1 implies that rev...@digicert.com 
  is for problem reporting. 

 

- Wayne

 

[1] https://www.digicert.com/wp-content/uploads/2019/04/DigiCert_CPS_v418.pdf

 

On Thu, May 9, 2019 at 3:46 PM Andrew Ayer via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

On Thu, 9 May 2019 14:47:05 +
Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:

> Hi Han - the proper alias is rev...@digicert.com  
> . The support alias
> will sometimes handle these, but not always.

Is that also true of SSL certificates?  supp...@digicert.com 
  is listed
first at
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport

That should be fixed if supp...@digicert.com   is 
not the right place to
report problems with SSL certificates.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
 
https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Reported Digicert key compromise but not revoked

[Wayne Thayer via dev-security-policy]

DigiCert CPS section 1.5.2 [1] could also more clearly state that
rev...@digicert.com is the correct address for 'reporting suspected Private
Key Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to
Certificates.' Since both email addresses are listed in that section, it's
not difficult to mistake supp...@digicert.com as the problem reporting
mechanism, even though the last sentence in 1.5.2.1 implies that
rev...@digicert.com is for problem reporting.

- Wayne

[1]
https://www.digicert.com/wp-content/uploads/2019/04/DigiCert_CPS_v418.pdf

On Thu, May 9, 2019 at 3:46 PM Andrew Ayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 9 May 2019 14:47:05 +
> Jeremy Rowley via dev-security-policy
>  wrote:
>
> > Hi Han - the proper alias is rev...@digicert.com. The support alias
> > will sometimes handle these, but not always.
>
> Is that also true of SSL certificates?  supp...@digicert.com is listed
> first at
>
> https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport
>
> That should be fixed if supp...@digicert.com is not the right place to
> report problems with SSL certificates.
>
> Regards,
> Andrew
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Reported Digicert key compromise but not revoked

[Jeremy Rowley via dev-security-policy]

Thanks Andrew. Yes - it should be rev...@digicert.com

-Original Message-
From: Andrew Ayer  
Sent: Thursday, May 9, 2019 4:46 PM
To: Jeremy Rowley 
Cc: Jeremy Rowley via dev-security-policy

Subject: Re: Reported Digicert key compromise but not revoked

On Thu, 9 May 2019 14:47:05 +
Jeremy Rowley via dev-security-policy
 wrote:

> Hi Han - the proper alias is rev...@digicert.com. The support alias 
> will sometimes handle these, but not always.

Is that also true of SSL certificates?  supp...@digicert.com is listed first
at
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsRepo
rt

That should be fixed if supp...@digicert.com is not the right place to
report problems with SSL certificates.

Regards,
Andrew



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Reported Digicert key compromise but not revoked

[Andrew Ayer via dev-security-policy]

On Thu, 9 May 2019 14:47:05 +
Jeremy Rowley via dev-security-policy
 wrote:

> Hi Han - the proper alias is rev...@digicert.com. The support alias
> will sometimes handle these, but not always.

Is that also true of SSL certificates?  supp...@digicert.com is listed
first at
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport

That should be fixed if supp...@digicert.com is not the right place to
report problems with SSL certificates.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Reported Digicert key compromise but not revoked

[Daniel Marschall via dev-security-policy]

I personally do think that it matters to this forum. A CA - no matter what kind 
of certificates it issues - must take revocation requests seriously and act 
immediately, even if the email is sent to the wrong address. If an employee at 
the help desk is unable to forward revocation requests, or needs several weeks 
to reply, then there is something not correct with the CA, no matter if the 
revocation request is related to a web certificate or code signing certificate. 
That's my opinion on this case.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

[Brian Smith via dev-security-policy]

On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer  wrote:

> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi  wrote:
>
>> Thank you David and Ryan! This appears to me to be a reasonable
>> improvement to our policy.
>>
>
> Brian: could I ask you to review the proposed change?
>
>
>> This does not, however, address the last part of what Brian proposes -
>> which is examining if, how many, and which CAs would fail to meet these
>> encoding requirements today, either in their roots, subordinates, or leaf
>> certificates.
>>
>>
> While I agree that this would be useful information, for the purpose of
> moving ahead with this policy change would it instead be reasonable to set
> an effective date and require certificates issued (notBefore) after that
> date to comply, putting the burden on CAs to verify their implementations
> rather than relying on someone else to do that work?
>

My understanding here is that the proposed text is not imposing a new
requirement, but more explicitly stating a requirement that is already
imposed by the BRs. AFAICT BRs require syntactically valid X.509
certificates, RFC 5280 defines what's syntactically valid, RFC 5280 defers
to other documents about what is allowed for each algorithm identifier, and
this is an attempt to collect all those requirements into one spot for
convenience.

It would be easier to understand if this is true if the proposed text cited
the RFCs, like RFC 4055, that actually impose the requirements that result
in the given encodings.


>
> While this includes RSA-PSS, it's worth noting that mozilla::pkix does not
>> support these certificates, and also worth noting that the current encoding
>> scheme is substantially more verbose than desirable.
>>
>
I agree the encoding is unfortunate. But, also, there's no real prospect of
a shorter encoding being standardized and implemented in a realistic time
frame.

Cheers,
Brian
--
https://briansmith.org/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certinomis Issues

[fchassery--- via dev-security-policy]

Le mardi 16 avril 2019 20:44:41 UTC+2, Wayne Thayer a écrit :
> Mozilla has decided that there is sufficient concern [1] about the
> activities and operations of the CA Certinomis to collect together a list
> of issues. That list can be found here:
> https://wiki.mozilla.org/CA/Certinomis_Issues
> 
> Note that this list may expand or contract over time as issues are
> investigated further, with information either from our or our community's
> investigations or from Certinomis.
> 
> We expect Certinomis to engage in a public discussion of these issues and
> give their comments and viewpoint. We also hope that our community will
> make comments, and perhaps provide additional information based on their
> own investigations.
> 
> When commenting on these issues, please clearly state which issue you are
> addressing on each occasion. The issues have been given identifying letters
> and numbers to help with this.
> 
> At the end of a public discussion period between Mozilla, our community,
> and Certinomis, which we hope will be no longer than a couple of weeks,
> Mozilla will move to make a decision about how to respond to these
> concerns, based on the picture which has then emerged.
> 
> - Wayne
> 
> [1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues

Dear All,

Before detailing my answer, I would like to refute opinions that Certinomis 
does not take these subjects seriously: since February the management of 
Certinomis was directly involved in the exchanges with the Mozilla community, 
decisions were made and are implemented.

I acknowledge that I was surprised by the multiple topics that were grouped by 
Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne 
THAYER for his analysis of a technical point of view that distinguished 
different categories of problems.

For my part, my role is above all to advance the practice of Certinomis, and 
for this I must classify the problems according to their cause, because the 
best way to solve a problem is to correct its cause. And I will allow myself to 
structure my answer according to this classification that I made of problems, 
reserving for the end the Issue A (Startcom Signing) that I really did not 
expect to hear about.

- First cause of problems: An organization of the technical direction not 
adapted to the plan of charge in 2018

In 2018, Certinomis carried out several projects to renew its technical 
capabilities (new production site, new PKI software, adaptation to BR 1.6.5, 
among others). Franck as our Technical Director led all this work. And at the 
same time, Frank was Mozilla’s only point of contact. Inevitably there has been 
errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 
comment#20 and answer that are part of Issue F3) and low reactivity (Issue B 
until November 2018) and perhaps editorial errors when updating PCs and DPCs 
(for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the 
description, in English, is that of rule 3.2.2.4.6)

-->Response to Cause 1: 

   - Action 1: 
   Franck’s departure was an opportunity to restructure Certinomis’ technical   
  management with three roles for caring of SSL activity.
- an internal audit team independent of the project management is in place; the 
structure that ensures it has implemented a daily linting post-issuance control 
since April 1st, to allow us to detect without delay any possible mistake.
- An employee of the quality team of Certinomis will be designated as the main 
contact of the CA/B Forum and Mozilla (but not the only point of contact).
To be complete on this topic the transition between Franck and another person 
had been prepared during the three months following his decision to leave.
But it soon became clear that the person chosen was not fitted to the role. It 
is for this reason that I have resumed the discussion with Mozilla personally, 
and I intend to remain engaged on the subject until the situation is stabilized.
-- PKI’s project management will carry out changes, settings and corrections.

The idea is to separate those who propose the evolutions, those who realize 
them and those who control them. In this way each one carries out his task 
without being inhibited by the constraints of the other.

- Second cause of problem: insufficient syntax control for certificate request 
processed by Enterprise RAs.

Several problems have been reported for certificates issued for the domains 
"laposte.fr" and "labanquepostale.fr".
La Poste and La Banque Postale belong to the La Poste group, as well as 
Certinomis. For each of these two companies an external RA was set up by 
Certinomis, to facilitate the issuance of certificates on the two domains 
controlled by these two companies. The ownership of domain names and the 
authorisation of operators have been established beforehand.
In this context, it has recently happened that CSRs generated by technicians on 
their servers are inserted by 

RE: Reported Digicert key compromise but not revoked

[Jeremy Rowley via dev-security-policy]

Hi Han - the proper alias is rev...@digicert.com. The support alias will
sometimes handle these, but not always. We picked up the request from your
post here and are working on it.

Of course, this is out of scope of the Mozilla policy since its code signing
only. 

-Original Message-
From: dev-security-policy  On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, May 9, 2019 8:37 AM
To: Han Yuwei 
Cc: mozilla-dev-security-policy

Subject: Re: Reported Digicert key compromise but not revoked

On Thu, May 9, 2019 at 8:59 AM Han Yuwei via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi m.d.s.p
> I have reported a key compromise incident to digicert by contacting 
> support(at)digicert.com at Apr.13, 2019 and get replied at same day. 
> But it seems like this certificate is still valid.
> This certificate is a code signing certificate and known for signing 
> malware. So I am here to report this to Digicert. If private key is 
> needed I will attach it.
>
> Certificate Info.
> CN:Beijing Founder Apabi Technology Limited
> SN: 06B7AA2C37C0876CCB0378D895D71041
> SHA1: 8564928AA4FBC4BBECF65B402503B2BE3DC60D4D
>

Typically, we have not dealt with issues related to code signing in this
forum - particularly the evaluation and enforcement of policies. For
example, the information provided doesn't allow us to distinguish whether
there is even a remote chance of overlap with the activity here (e.g. with
respect to audits and the CP/CPS)

Have you considered reporting this to Microsoft, as I presume that's the
platform concern?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Reported Digicert key compromise but not revoked

[Ryan Sleevi via dev-security-policy]

On Thu, May 9, 2019 at 8:59 AM Han Yuwei via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi m.d.s.p
> I have reported a key compromise incident to digicert by contacting
> support(at)digicert.com at Apr.13, 2019 and get replied at same day. But
> it seems like this certificate is still valid.
> This certificate is a code signing certificate and known for signing
> malware. So I am here to report this to Digicert. If private key is needed
> I will attach it.
>
> Certificate Info.
> CN:Beijing Founder Apabi Technology Limited
> SN: 06B7AA2C37C0876CCB0378D895D71041
> SHA1: 8564928AA4FBC4BBECF65B402503B2BE3DC60D4D
>

Typically, we have not dealt with issues related to code signing in this
forum - particularly the evaluation and enforcement of policies. For
example, the information provided doesn't allow us to distinguish whether
there is even a remote chance of overlap with the activity here (e.g. with
respect to audits and the CP/CPS)

Have you considered reporting this to Microsoft, as I presume that's the
platform concern?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

[Ryan Sleevi via dev-security-policy]

On Wed, May 8, 2019 at 10:36 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> [ Note, I am arguing a neutral position on the specific proposal ]
>
> The common purpose of having an internally secured (managed or on-site)
> CA in a public hierarchy is to have end certificates which are
> simultaneously:
>

Despite my years of close experience with the implementation and details of
the certificate verification engines within Google Chrome and Android,
Mozilla Firefox, Apple iOS and macOS, and Microsoft Windows, including
extensive work with Enterprise PKIs, I must admit, I have never heard of
the scenario you're describing or actually being supported.

Given that the remark is that such a desire is common, perhaps you can
provide some external references documenting how one might go about
configuring such a set-up, particularly in the context of TLS trust?
Similarly, I'm not aware of any system that supports binding S/MIME
identities to a particularly CA (effectively, CA pinning) - perhaps you can
provide documentation and reference for systems that perform this?

Thanks for helping me understand how this 'common' scenario is actually
implemented, especially given that the underlying codebases do not support
such distinctions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reported Digicert key compromise but not revoked

[Han Yuwei via dev-security-policy]

Hi m.d.s.p
I have reported a key compromise incident to digicert by contacting 
support(at)digicert.com at Apr.13, 2019 and get replied at same day. But it 
seems like this certificate is still valid.
This certificate is a code signing certificate and known for signing malware. 
So I am here to report this to Digicert. If private key is needed I will attach 
it.

Certificate Info.
CN:Beijing Founder Apabi Technology Limited
SN: 06B7AA2C37C0876CCB0378D895D71041
SHA1: 8564928AA4FBC4BBECF65B402503B2BE3DC60D4D
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy