Re: DigiCert-Symantec Announcement

[Peter Kurrasch via dev-security-policy]

  I agree with the high-level concepts, although I would probably like to add something about "being good stewards of technologies that play a critical role in the global economy." (Feel free to use your own words!)Regarding the current Mozilla/Google plans, I don't necessarily have a problem with them but I do think we should give ourselves permission to make adjustments (if needed) because the circumstances have changed since those plans were developed. Consider:* Because the acquisition is now in the picture, legal issues might impede progress in certain areas. The most notable example is the fact that DigiCert will have limited authority over Symantec until the deal actually closes. For example, what will happen in the period between Dec 1 and the closing (assuming it's after the first)?* Once the deal does close, personnel and management issues could present various challenges in meeting certain deadlines. For example, if subject matter experts decide to leave Symantec prior to the closing, how might that hinder DigiCert?* A lot of churn is about to be introduced in the global PKI. Times of chaos create moments of opportunity for those who wish to do bad things. Should something happen, corrections may be necessary which can impact delivery dates, and so on.Let me be clear that these are just hypothetical situations and rhetorical questions. I don't expect answers and my only intention is to get people to start thinking about these matters (if they haven't already begun).Hopefully this better explains where I was coming from in my initial reply.From: Jeremy RowleySent: Thursday, August 3, 2017 8:13 PM‎ Hey Peter,  I think the Mozilla and Google plans both stand as-is, although probably need an updated based on this announcement.  I'm hoping that the high-level concepts remain unchanged:    - Migrate to a new infrastructure    - Audit the migration and performance to ensure compliance    - Improve operational transparency so the community has assurances on what is happening.  Jeremy  This certainly shakes things up! I've had my concerns that Symantec's plan was complicated and risky, but now I'm wondering if this new path will be somewhat simpler--yet even more risky? I'm not suggesting we shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the waysnip...* I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[J.C. Jones via dev-security-policy]

On 8/3/17 5:27 PM, Kathleen Wilson via dev-security-policy wrote:
> On Thursday, August 3, 2017 at 4:34:27 PM UTC-7, Ryan Sleevi wrote:
> In bug #1311832 there is a note about cross-signing:
> "[1] The new (replacement) root certificates may be cross-signed by the 
> Affected Roots. However, the Affected Roots may *not* be cross-signed by the 
> new (replacement) root certificates, because that would bring the concerns 
> about the Affected Roots into the scope of the new roots. Due to the way we 
> are implementing the distrust, the new root certificates must have a Subject 
> Distinguished Name that does not overlap with the Subject Distinguished Names 
> listed above."
>
> I don't see anything expressly forbidding cross-signing of new roots, but 
> perhaps that was an oversight.

The issue in my eyes isn't necessarily the cross-signature (though the
delay in disclosure is a problem), it's using a publicly-trusted CA to
fine-tune the issuance process.

It's perfectly understandable to sign invalid certificates that violate
aspects of root policies and the BRs while proceeding with your test
plan. I've certainly done that myself. It's not acceptable to me that
the test plan used a CA that either already was or subsequently became
publicly-trusted.

This is a professional PKI operation, being overseen by industry
veterans. If something as concrete as the issuance process had such a
glaring quality assurance methodology failure, why should anyone believe
that something much harder -- subscriber validation -- is going to be
done correctly?

I agree that Mozilla should add these intermediates to OneCRL.

> Along this line of discussion, I have not felt comfortable with StartCom's 
> current root inclusion request (bug #1381406), because Hanno raised a concern 
> about the private key used by the new root is also used by two intermediate 
> certificates, one of them revoked. This doesn't see like good practice to me, 
> and I'm not sure that Inigo's response is sufficient. So, I'm also wondering 
> if I should close Bug #1381406 and request StartCom to start completely over 
> with their new CA Hierarchy, and get it right, before creating their next 
> root inclusion request.

I agree, it's not good practice, even if it's not prohibited. Since this
brings it up, we should consider prohibiting it going forward. Keys, and
space on HSMs for keys, are certainly not free, but they aren't so
expensive that the Web PKI should suffer the costs of ambiguous mappings
of keys to CAs.

CRLs and OneCRL revoke trust based on issuer/serial combinations. If
this key were compromised in some way, we would need to have knowledge
of, and revoke, all combinations. We've discussed before needing a way
through OneCRL (or OneCRL 2.0) to revoke based on public key hash; this
is part of the reason why.

J.C.

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

Re: StartCom cross-signs disclosed by Certinomis

[Matt Palmer via dev-security-policy]

On Thu, Aug 03, 2017 at 08:47:17AM +, Inigo Barreira via 
dev-security-policy wrote:
> And what I don´t understand are those comments of "very sloppy isuance
> practices" , "many non-BR compliants", "specially given the historic issues
> with StartCom" and consider them very unfair. These are subjective opinions
> which are very dangerous and not fair. 

Fairness is not, as far as I'm aware, a criteria for inclusion in the
Mozilla root store.

> This is a totally new system that is not related with "the historic issues"
> at all, so whatever happened in the past is not related (and we could talk a
> lot of why StartCom was distrusted in the past), only the name is the same.

Systems are not limited to software and hardware.  They also include the
people, and at least some of the people in "the system" are the same. 
Further, if "the system" *were* completely new and improved, why is it still
producing problematic certificates and generally looking, from the outside,
like a complete and utter shambles?

> Finally I´d like to understand also why has been asked to create OneCRL
> entries for these subCAs.

Because the intermediates chain to a CA certificate which represents a
demonstrably broken and untrustworthy system, and distrusting the
intermediates has no visible impact on the relying parties which the Mozilla
trust store represents.

- Matt

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

Re: StartCom cross-signs disclosed by Certinomis

[Matt Palmer via dev-security-policy]

On Thu, Aug 03, 2017 at 11:20:19AM +, Inigo Barreira via 
dev-security-policy wrote:
> We´re revoking all those unrevoked certs to avoid any more problems.

Revoking problematic certificates doesn't avoid any problems.  The problems
have already been created.

> Regarding the pre-certs, yes, I was aware of the discussion. As Gerv says
> there´s a binding statement of "intent" ... the problem with these is that
> we generated the pre-certs and logged in the CT log, where crt.sh looks or
> monitor, but those weren´t finally issued, so there are not such certs.

I don't understand how failing to issue a certificate corresponding to a
logged pre-certificate constitutes a "problem".  You logged the pre-cert. 
It was broken.  There's the problem.

- Matt

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

Re: StartCom cross-signs disclosed by Certinomis

[Matt Palmer via dev-security-policy]

On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> However, I think it is fine for Certinomis to cross-sign with new StartCom
> subCA certs, as long as Certinomis ensures that Mozilla's Root Store
> Policy is being followed.

... which they didn't.  So there's that.

> > 1) Many of the certificates are improperly validated “test”
> > certificates, a practice that is extremely problematic and indicates a
> > lack of or circumvention of technical controls.
> 
> Yes, this is problematic.  But other CAs have also had this problem, and
> for the other CAs we have worked with them to ensure the practice is
> stopped, tools/process put in place to prevent it in the future,
> problematic certs revoked, etc.  But this type of mis-issuance has not yet
> been considered grounds for adding the relevant intermediate cert to
> OneCRL.

Those are CAs which have been operational for some time though, and which
have certificates "in the wild" which would be distrusted, correct?  That's
a somewhat different case to this one, where nothing important is hanging
off the intermediate, so distrusting it doesn't hurt relying parties, only
the CA -- which is fine, because it's the CA's fault the distrust is
required, so it's entirely self-inflicted pain.

- Matt

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

RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Hey Peter, 



 I think the Mozilla and Google plans both stand as-is, although probably need 
an updated based on this announcement.  I'm hoping that the high-level concepts 
remain unchanged:

- Migrate to a new infrastructure

- Audit the migration and performance to ensure compliance

- Improve operational transparency so the community has assurances on what 
is happening. 



 Jeremy

 

 

From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Peter Kurrasch via dev-security-policy
Sent: Wednesday, August 2, 2017 8:01 PM
To: mozilla-dev-security-policy 
Subject: Re: DigiCert-Symantec Announcement

 

This certainly shakes things up! I've had my concerns that Symantec's plan was 
complicated and risky, but now I'm wondering if this new path will be somewhat 
simpler--yet even more risky? I'm not suggesting we shouldn't take this path 
but I am hoping we make smart, well-thought-out decisions along the way.

 

Some thoughts:

 

* Will there be other players in Symantec's SubCA plan or is DigiCert the only 
one?

 

* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the 
SubCA plan? That is, when is the earliest date that members of the general 
public may purchase certs that chain up through the new "DigiCert SubCA" to any 
of the Symantec roots? I hope that, for issues that may arise under the new 
system, there is sufficient time to identify and resolve them prior to the 
2017-12-01 deadline.





* I think the idea of a smart segregation plan for the roots and intermediates 
is a must-have. Such a plan should factor in the clientele who are using the 
different roots and the environments in which they operate. Given how important 
the "ubiquitous roots" are, I would hope to see community involvement and 
"sign-off", if you will.

 

* I think it's appropriate to re-think some of the deadlines, given that we're 
talking less about a carrots-and-sticks model and more of one based on smart 
decision-making, good risk management, and sticks.









Finally, when I went to read the DigiCert blog post, I noticed that John 
Merrill's link for the agreement announcement was a dud. I don't know why but I 
really don't care either. I think it serves as a reminder ‎that mistakes are 
going to be made during this process so it's best to make allowances for that 
in the plans going forward. That, and attention to detail is important.





Thanks.



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: StartCom cross-signs disclosed by Certinomis

[Matt Palmer via dev-security-policy]

On Thu, Aug 03, 2017 at 05:27:03PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> Along this line of discussion, I have not felt comfortable with StartCom's
> current root inclusion request (bug #1381406), because Hanno raised a
> concern about the private key used by the new root is also used by two
> intermediate certificates, one of them revoked.  This doesn't see like
> good practice to me, and I'm not sure that Inigo's response is sufficient. 
> So, I'm also wondering if I should close Bug #1381406 and request StartCom
> to start completely over with their new CA Hierarchy, and get it right,
> before creating their next root inclusion request.

I think it makes the most sense to ask StartCom to start "clean", as well. 
Hierarchies that are to be globally trusted should not be used as
"experimental playgrounds", even if those experiments are revoked, because
as we all know revocation is not 100% effective.

Further, if Mozilla allows the existing hierarchy to be admitted, there's no
demonstration that StartCom is actually *capable* of doing things correctly. 
A fully compliant hierarchy would be a demonstration that they *do* know
how, and got it wrong last time, as opposed to being incapable.  Once
there's a fully-compliant setup in place, there's then no reason to use a
broken setup, given that it isn't currently used by anyone, anyway.

- Matt

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

RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

We aren't sure at this point. DigiCert already runs two (almost three) logs.
Symantec runs two logs.  Although CT plans are still under discussion, I
don't think the ecosystem needs four CT logs operated by a single CA.
Regardless, we'll do whatever is best to support CT and the DigiCert and
Symantec customer-base. Likely, we'll compare infrastructure and keep the
best performing logs. We'll definitely run a differential between the logs
and consult with the community before anything is done with existing logs. 
Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Santhan Raj via dev-security-policy
Sent: Thursday, August 3, 2017 1:36 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On Wednesday, August 2, 2017 at 6:44:51 PM UTC-7, Peter Bowen wrote:
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy 
>  wrote:
> > Today, DigiCert and Symantec announced that DigiCert is acquiring 
> > the Symantec CA assets, including the infrastructure, personnel, 
> > roots, and platforms.  At the same time, DigiCert signed a Sub CA 
> > agreement wherein we will validate and issue all Symantec certs as 
> > of Dec 1, 2017.  We are committed to meeting the Mozilla and Google 
> > plans in transitioning away from the Symantec infrastructure. The 
> > deal is expected to close near the end of the year, after which we will
be solely responsible for operation of the CA.
> > From there, we will migrate customers and systems as necessary to 
> > consolidate platforms and operations while continuing to run all 
> > issuance and validation through DigiCert.  We will post updates and 
> > plans to the community as things change and progress.
> >
> > Thanks a ton for any thoughts you offer.
> 
> Jeremy,
> 
> A while ago I put together a list of all the certificates that are or 
> were included in trust stores that were known to be owned by Symantec 
> or companies that Symantec acquired.  The list is in Google Sheets at 
> https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdR
> DGFuGehdzcvo8/edit?usp=sharing
> 
> Can you confirm that DigiCert will be "solely responsible for 
> operation" of all of these CAs once the deal closes?
> 
> Thanks,
> Peter

Hi Jeremy,

A similar question regarding Symantec's CT log infrastructure. Are they part
of the deal and do you plan to continue hosting them?

Thanks,
Santhan
___
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: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Hi Doug,

We are confident in our ability to hit the deadlines set by both Mozilla and 
Google. Our understanding is that all new validations will be done by DigiCert 
on Dec 1, 2017. We plan to start re-validating information as soon as 
practical under the Sub CA agreement. Our mutual goal is to avoid Symantec 
validation data reuse, avoiding the shorter validity periods required by 
Google.  Both companies believe this will provide the best customer experience 
and give customers the service they are used to.

Jeremy

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Jeremy Rowley via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:54 PM
> To: Peter Kurrasch ; mozilla-dev-security-policy
> 
> Subject: RE: DigiCert-Symantec Announcement
> * Will there be other players in Symantec's SubCA plan or is DigiCert
> the only one?
>
>
>
> [DC] Only DigiCert.

Jeremy - It's my understanding that as of December 1st every certificate 
issued by Symantec or a Managed CA must have the domains validated by the 
Managed CA (in this case only DigiCert). Is it feasible that DigiCert 
revalidate every domain in use by Symantec Enterprise customs between now and 
then, and to keep up with all reissues/renewals and new Retail and Partner 
orders?  It seems like a huge challenge, especially given that you are not 
able to use Symantec employees or systems for this.  Maybe my assumptions are 
not accurate.



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: Certificate with invalid dnsName issued from Baltimore intermediate

[Matt Palmer via dev-security-policy]

On Thu, Aug 03, 2017 at 02:38:33PM +, Ben Wilson via dev-security-policy 
wrote:
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:

[...]

> Concerning the CA revocation, first of all, I want to underline that for us
> it would be a major issue: we don't have enough time and resources to
> replace all the certificates before the end of the year and the revocation
> of the CA will cause us several critical operating problems with our
> infrastructural services.

They don't appear to have enough time and resources to run a CA properly,
either, and the non-revocation of the CA certificate causes the rest of the
Internet critical security problems.

Adding the intermediate to OneCRL and revoking on 15th August seems like a
reasonable compromise to solve an issue that is, when all is said and done,
entirely of their own making.  December 31, being nearly five months away,
is far too long, IMO.

A 15th August deadline gives them 10 days to replace 300 public certs, which
is 30 certs to do per day...  that seems reasonable for one person to do,
and I'm sure there's more than one person at **a bank that runs its own CA**
who can do certificate replacements.

If that's considered too aggressive a deadline, I'd ask Intesa Sanpaolo what
their *absolute* earliest possible date for non-disruptive distrust would be. 
Then we can decide if that's reasonable or not.

- Matt

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

Re: DigiCert-Symantec Announcement

[Jakob Bohm via dev-security-policy]

On 02/08/2017 23:12, Jeremy Rowley wrote:

Hi everyone,

  


Today, DigiCert and Symantec announced that DigiCert is acquiring the
Symantec CA assets, including the infrastructure, personnel, roots, and
platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
will validate and issue all Symantec certs as of Dec 1, 2017.  We are
committed to meeting the Mozilla and Google plans in transitioning away from
the Symantec infrastructure. The deal is expected to close near the end of
the year, after which we will be solely responsible for operation of the CA.

From there, we will migrate customers and systems as necessary to

consolidate platforms and operations while continuing to run all issuance
and validation through DigiCert.  We will post updates and plans to the
community as things change and progress.

  


Wasn't the whole outsourced SubCA plan predicated on the outsourcing
being done to someone else.  But with this, DigiCert (as successor to
Symantec) would be outsourcing to itself?



I wanted to post to the Mozilla dev list to:

1.  Inform the public,
2.  Get community feedback about the transition and concerns, and
3.  Get an update from the browsers on what this means for the plan,
noting that we fully commit to the stated deadlines. We're hoping that any
changes

  


Two things I can say we plan on doing (following closing) to address
concerns are:

a.  We plan to segregate certs by type on each root. Going forward, we
will issue all SSL certs from a root while client and email come from
different roots. We also plan on limiting the number of organizations on
each issuing CA.  We hope this will help address the "too big to fail" issue
seen with Symantec.  By segregating end entities into roots and sub CAs, the
browsers can add affected Sub CAs to their CRL lists quickly and without
impacting the entire ecosystem.  This plan is very much in flux, and we'd
love to hear additional recommendations.
b.  Another thing we are doing is adding a validation OID to all of our
certificates that identifies which of the BR methods were used to issue the
cert. This way the entire community can readily identify which method was
used when issuing a cert and take action if a method is deemed weak or
insufficient.  We think this is a huge improvement over the existing
landscape, and I'm very excited to see that OID rolled out.



If you take over the roots, why continue to keep separate roots for the
former Symantec brands (except as an "old hierarchy used mostly for
their own CRLs and historic relying parties such as certain Microsoft
products")?


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: StartCom cross-signs disclosed by Certinomis

[Kathleen Wilson via dev-security-policy]

On Thursday, August 3, 2017 at 4:34:27 PM UTC-7, Ryan Sleevi wrote:
> I do hope you can clarify whether remediations apply to keys operated by 
> organizations, or whether they apply to the organization themselves. 

https://bugzilla.mozilla.org/show_bug.cgi?id=1311832
says: "StartCom may apply for inclusion of new (replacement) root 
certificates[1] following Mozilla's normal root inclusion/change process[2] 
(minus waiting in the queue for the discussion), after they have completed all 
of the following action items, and shown that WoSign has no control (people or 
code) over StartCom."

So, the remediations do apply to the organization.


> If they apply to the organization, one would naturally expect they apply to 
> root inclusion or cross-signs, and the organization is no longer "treated 
> like a new CA," because they are no longer a new CA - they are an existing 
> one.
> 


OK. Clearly I hadn't thought of it this way.


> It is also worth noting that in the past, Mozilla directed other CAs that 
> cross-signing of their (new) roots would be expressly forbidden until the 
> corrective actions were taken and publicly reviewed. For example, allowing 
> CNNIC to be cross-signed prior to remediation would have defeated the entire 
> purpose of removal.


In bug #1311832 there is a note about cross-signing:
"[1] The new (replacement) root certificates may be cross-signed by the 
Affected Roots. However, the Affected Roots may *not* be cross-signed by the 
new (replacement) root certificates, because that would bring the concerns 
about the Affected Roots into the scope of the new roots. Due to the way we are 
implementing the distrust, the new root certificates must have a Subject 
Distinguished Name that does not overlap with the Subject Distinguished Names 
listed above."

I don't see anything expressly forbidding cross-signing of new roots, but 
perhaps that was an oversight.


> 
> In this larger light, it would also seem that StartCom, having misissued a 
> number of certificates already under their new hierarchy, which present a 
> risk to Mozilla users (revocation is neither an excuse nor a mitigation for 
> misissuance), should be required to take corrective steps and generate a new 
> hierarchy that is not, out of the gate, presenting risk to the overall 
> community due to its past misissuances. We can and should expect more of new 
> keys being included, because the compatibility risk of expecting adherence to 
> the Root Policy is non-existent.


To me, this is very convincing that we should add the two StartCom intermediate 
certs to OneCRL.

Along this line of discussion, I have not felt comfortable with StartCom's 
current root inclusion request (bug #1381406), because Hanno raised a concern 
about the private key used by the new root is also used by two intermediate 
certificates, one of them revoked. This doesn't see like good practice to me, 
and I'm not sure that Inigo's response is sufficient. So, I'm also wondering if 
I should close Bug #1381406 and request StartCom to start completely over with 
their new CA Hierarchy, and get it right, before creating their next root 
inclusion request.

I will appreciate thoughtful and constructive feedback on this as well.

Thanks,
Kathleen




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

Re: StartCom cross-signs disclosed by Certinomis

[Ryan Sleevi via dev-security-policy]

On Friday, August 4, 2017 at 8:02:16 AM UTC+9, Kathleen Wilson wrote:
> On Thursday, August 3, 2017 at 3:09:25 PM UTC-7, Kurt Roeckx wrote:
> > I would really like to see that they have at least opened a bug to
> > request the inclusion of that CA before it's cross-signed. 
> 
> Here's StartCom's current root inclusion request:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1381406
> 
> 
> > It should
> > have already all the requirements that Mozilla has for including the
> > root CA certificate before it's cross signed.
> 
> Correct. That should be true for all subCAs that are cross-signed by 
> currently-included CAs.
> 
> > 
> > I would prefer that it's even included in the Mozilla root store
> > before it's cross signed, 
> 
> That might not be fair, given how long Mozilla's root inclusion process 
> takes, and that we don't require this of other CAs who are new to our program.

Kathleen,

Doesn't this depend on your perspective of whether or not "new CA" refers to 
the key or the organization?

There's no doubt StartCom is not a "new CA" - it is a CA that Mozilla entrusted 
with the ability to issue certificates, and the organization - and its 
management - egregiously and repeatedly violated that trust.

The decision to remove - and to instill new requirements - was to ensure that 
the organization meaningfully underwent change to ensure that it would not do 
the same if further keys operated by it were included as trusted by Mozilla 
products - whether directly or indirectly.

Further, the process of restricting it to going through the Mozilla process 
ensures that there is a sufficient level of community review of those 
remediation steps, so that the Mozilla community can be assured that StartCom, 
the organization, is both competent enough and trustworthy enough to be 
entrusted with keys to the Internet.

In this light, both the past actions of StartCom the organization AND the many 
technical failures are relevant in that evaluation. Cross-signing directly 
undermines that review process, and in doing so, undermines both trust in 
StartCom the organization and in the Mozilla process, if a removed CA need only 
to pay for a cross-sign and can thus bypass every remediation step required of 
them, as StartCom is effectively doing.

My understanding had been that when a remediation is imposed on an 
organization, due to failing to follow policies, then those remediation steps 
must be taken, and subsequently reviewed by the community, before any direct 
(root key inclusion) or indirect (cross-signing) restoration of trust in the 
Mozilla Root Store. Without that guarantee, any corrective actions are hollow, 
and with it, trust in the whole system itself is lost.

I do hope you can clarify whether remediations apply to keys operated by 
organizations, or whether they apply to the organization themselves. If they 
apply to the organization, one would naturally expect they apply to root 
inclusion or cross-signs, and the organization is no longer "treated like a new 
CA," because they are no longer a new CA - they are an existing one.

It is also worth noting that in the past, Mozilla directed other CAs that 
cross-signing of their (new) roots would be expressly forbidden until the 
corrective actions were taken and publicly reviewed. For example, allowing 
CNNIC to be cross-signed prior to remediation would have defeated the entire 
purpose of removal.

In this larger light, it would also seem that StartCom, having misissued a 
number of certificates already under their new hierarchy, which present a risk 
to Mozilla users (revocation is neither an excuse nor a mitigation for 
misissuance), should be required to take corrective steps and generate a new 
hierarchy that is not, out of the gate, presenting risk to the overall 
community due to its past misissuances. We can and should expect more of new 
keys being included, because the compatibility risk of expecting adherence to 
the Root Policy is non-existent.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Kathleen Wilson via dev-security-policy]

On Thursday, August 3, 2017 at 3:09:25 PM UTC-7, Kurt Roeckx wrote:
> I would really like to see that they have at least opened a bug to
> request the inclusion of that CA before it's cross-signed. 

Here's StartCom's current root inclusion request:
https://bugzilla.mozilla.org/show_bug.cgi?id=1381406


> It should
> have already all the requirements that Mozilla has for including the
> root CA certificate before it's cross signed.

Correct. That should be true for all subCAs that are cross-signed by 
currently-included CAs.

> 
> I would prefer that it's even included in the Mozilla root store
> before it's cross signed, 

That might not be fair, given how long Mozilla's root inclusion process takes, 
and that we don't require this of other CAs who are new to our program.

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

Re: Remove old WoSign root certs from NSS

[Kathleen Wilson via dev-security-policy]

On Monday, July 10, 2017 at 12:47:31 PM UTC-7, Kathleen Wilson wrote:
> I also think we should remove the old WoSign root certs from NSS.
> 
> Reference:
> https://wiki.mozilla.org/CA/Additional_Trust_Changes#WoSign
> ~~
> Mozilla currently recommends not trusting any certificates issued by this CA 
> after October 21st, 2016. That recommendation covers the following roots:
> 
> CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
> CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
> CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, 
> C=CN
> CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
> 
> This restriction has been implemented in both in the Mozilla platform 
> security code (PSM), which is shared by the Mozilla applications (Firefox, 
> Thunderbird, etc.), and in addition, in the NSS library code, which is used 
> by applications that use the NSS certificate verification APIs. 
> ~~
> 
> Please let me know if you foresee any problems with removing these root certs 
> from NSS.
> 
> Thanks,
> Kathleen


I have filed Bug #1387260 to remove the old WoSign root certificates. This will 
likely happen in the October batch of root changes.

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

Re: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

I believe all of the non expired CAs listed are in scope.

> On Aug 2, 2017, at 7:44 PM, Peter Bowen  wrote:
> 
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
>  wrote:
>> Today, DigiCert and Symantec announced that DigiCert is acquiring the
>> Symantec CA assets, including the infrastructure, personnel, roots, and
>> platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
>> will validate and issue all Symantec certs as of Dec 1, 2017.  We are
>> committed to meeting the Mozilla and Google plans in transitioning away from
>> the Symantec infrastructure. The deal is expected to close near the end of
>> the year, after which we will be solely responsible for operation of the CA.
>> From there, we will migrate customers and systems as necessary to
>> consolidate platforms and operations while continuing to run all issuance
>> and validation through DigiCert.  We will post updates and plans to the
>> community as things change and progress.
>> 
>> Thanks a ton for any thoughts you offer.
> 
> Jeremy,
> 
> A while ago I put together a list of all the certificates that are or
> were included in trust stores that were known to be owned by Symantec
> or companies that Symantec acquired.  The list is in Google Sheets at
> https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdRDGFuGehdzcvo8/edit?usp=sharing
> 
> Can you confirm that DigiCert will be "solely responsible for
> operation" of all of these CAs once the deal closes?
> 
> Thanks,
> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Kurt Roeckx via dev-security-policy]

On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> On Thursday, August 3, 2017 at 9:49:41 AM UTC-7, Jonathan Rudenberg wrote:
> > Even absent the BR-violating certificates and disclosure timeline, I 
> > believe this cross-sign is problematic because it appears to circumvent the 
> > prerequisites and process described in 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 for StartCom’s 
> > application for re-inclusion into the Mozilla root store. It’s not clear to 
> > me what the point of those requirements is if they can be avoided by 
> > obtaining cross-signatures from other CAs that are currently trusted by 
> > Mozilla.
> 
> It is common practice for a CA to get cross-signed by a currently-included 
> CA, so their cert chain is trusted while they are going through Mozilla's 
> long inclusion process. This is OK, as long as the currently-included CA 
> ensures that the subCA follows Mozilla's Root Store Policy.
> See section 5.3 of 
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

I would really like to see that they have at least opened a bug to
request the inclusion of that CA before it's cross-signed. It should
have already all the requirements that Mozilla has for including the
root CA certificate before it's cross signed.

I would prefer that it's even included in the Mozilla root store
before it's cross signed, or that it's been added to one of the
other root stores.


Kurt

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

RE: DigiCert-Symantec Announcement

[Doug Beattie via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Jeremy Rowley via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:54 PM
> To: Peter Kurrasch ; mozilla-dev-security-policy
> 
> Subject: RE: DigiCert-Symantec Announcement
> * Will there be other players in Symantec's SubCA plan or is DigiCert the only
> one?
> 
> 
> 
> [DC] Only DigiCert.

Jeremy - It's my understanding that as of December 1st every certificate issued 
by Symantec or a Managed CA must have the domains validated by the Managed CA 
(in this case only DigiCert). Is it feasible that DigiCert revalidate every 
domain in use by Symantec Enterprise customs between now and then, and to keep 
up with all reissues/renewals and new Retail and Partner orders?  It seems like 
a huge challenge, especially given that you are not able to use Symantec 
employees or systems for this.  Maybe my assumptions are not accurate.

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

Re: DigiCert-Symantec Announcement

[Santhan Raj via dev-security-policy]

On Wednesday, August 2, 2017 at 6:44:51 PM UTC-7, Peter Bowen wrote:
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
>  wrote:
> > Today, DigiCert and Symantec announced that DigiCert is acquiring the
> > Symantec CA assets, including the infrastructure, personnel, roots, and
> > platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
> > will validate and issue all Symantec certs as of Dec 1, 2017.  We are
> > committed to meeting the Mozilla and Google plans in transitioning away from
> > the Symantec infrastructure. The deal is expected to close near the end of
> > the year, after which we will be solely responsible for operation of the CA.
> > From there, we will migrate customers and systems as necessary to
> > consolidate platforms and operations while continuing to run all issuance
> > and validation through DigiCert.  We will post updates and plans to the
> > community as things change and progress.
> >
> > Thanks a ton for any thoughts you offer.
> 
> Jeremy,
> 
> A while ago I put together a list of all the certificates that are or
> were included in trust stores that were known to be owned by Symantec
> or companies that Symantec acquired.  The list is in Google Sheets at
> https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdRDGFuGehdzcvo8/edit?usp=sharing
> 
> Can you confirm that DigiCert will be "solely responsible for
> operation" of all of these CAs once the deal closes?
> 
> Thanks,
> Peter

Hi Jeremy,

A similar question regarding Symantec's CT log infrastructure. Are they part of 
the deal and do you plan to continue hosting them?

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

Re: StartCom cross-signs disclosed by Certinomis

[Jonathan Rudenberg via dev-security-policy]

> On Aug 3, 2017, at 12:26, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
> All,
> 
> I have conflicting opinions about this situation:
> 
> On the one hand, I want to see better behavior, and am inclinded to add these 
> two intermediate certs to OneCRL, and tell StartCom and Certinomis to start 
> over and do things right.
> 
> On the other hand, I'm not convinced yet that the issued non-BR-compliant 
> certs are any worse than we've seen from other CAs for whom we tell them to 
> fix the problem but do not add their relevant intermediate certs to OneCRL.
> 
> Kathleen

Even absent the BR-violating certificates and disclosure timeline, I believe 
this cross-sign is problematic because it appears to circumvent the 
prerequisites and process described in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 for StartCom’s application 
for re-inclusion into the Mozilla root store. It’s not clear to me what the 
point of those requirements is if they can be avoided by obtaining 
cross-signatures from other CAs that are currently trusted by Mozilla.

As far as the misissued certificates are concerned, here are a couple points to 
consider:

1) Many of the certificates are improperly validated “test” certificates, a 
practice that is extremely problematic and indicates a lack of or circumvention 
of technical controls.

2) StartCom's systems are apparently new, but they have failed to correctly 
implement simple aspects of the certificate profile such as keyUsage bits and 
character encodings. These issues are trivially detected by running tools like 
certlint and should have been caught well before the system made it into 
production.

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

Re: StartCom cross-signs disclosed by Certinomis

[Kathleen Wilson via dev-security-policy]

All,

I have conflicting opinions about this situation:

On the one hand, I want to see better behavior, and am inclinded to add these 
two intermediate certs to OneCRL, and tell StartCom and Certinomis to start 
over and do things right.

On the other hand, I'm not convinced yet that the issued non-BR-compliant certs 
are any worse than we've seen from other CAs for whom we tell them to fix the 
problem but do not add their relevant intermediate certs to OneCRL.

Kathleen

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

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Thanks Jonathan

Yes, I answered after just looking quickly about the main issues not focusing 
on the different sizes, etc. As you can see in the post, we have revoked all of 
them.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: Jonathan Rudenberg [mailto:jonat...@titanous.com] 
Sent: jueves, 3 de agosto de 2017 16:52
To: Inigo Barreira 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis


> On Aug 3, 2017, at 04:47, Inigo Barreira via dev-security-policy 
>  wrote:
> 
> For those which are not revoked are due to use different curves 
> (P-384,
> P-521) that have been discussed in the mozilla m.d.s.p as well as the 
> CAB Forum and there´s no conclusion yet, but in any case we´re not 
> allowing to use them anymore. There´re curves allowed in the BRs that 
> Mozilla does not include.
> 
> 2. Other un-revoked certificates have the same error “ ERROR: 
> Unallowed key usage for EC public key (Key Encipherment) ”
> https://crt.sh/?opt=cablint=153404034
> https://crt.sh/?opt=cablint=160150786
> https://crt.sh/?opt=cablint=149445010
> https://crt.sh/?opt=cablint=150133570

Let’s break this down, as you have confused a few issues with this subset of 
the misissued certificates. Two certificates were issued with P-521 ECDSA keys, 
which is not allowed by Mozilla policy (note that P-384 keys are allowed):

- 
https://crt.sh/?q=87304EBF0F9391B8FFF7C8ED8D567F0340BCBAA6741972C030364DE5618C6757
- 
https://crt.sh/?q=962C955ABC03FC00F514EA41B2838D85826CA7CAA419A85EC186F1646AD5C9B5

Thirteen certificates (including the two P-521 certificates) were issued with 
the keyEncipherment bit set in the keyUsage extension (this is the message you 
mentioned above) which is not allowed (RFC 3279 section 2.3.5, incorporated by 
reference by RFC 5280 section 4.2.1.3, incorporated by reference by Baseline 
Requirements section 7.1.2.4).

One certificate linked above was issued without the key parameters field set, 
which is not allowed (RFC 3279 section 2.3.1, incorporated by reference by RFC 
5280 section 4.1.2.7, incorporated by reference by Baseline Requirements 
section 7.1.2.4):

- https://crt.sh/?opt=cablint=160150786

Hopefully this clarifies any misunderstandings around the problems with these 
specific certificates.

Jonathan


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: StartCom cross-signs disclosed by Certinomis

[Jonathan Rudenberg via dev-security-policy]

> On Aug 3, 2017, at 04:47, Inigo Barreira via dev-security-policy 
>  wrote:
> 
> For those which are not revoked are due to use different curves (P-384,
> P-521) that have been discussed in the mozilla m.d.s.p as well as the CAB
> Forum and there´s no conclusion yet, but in any case we´re not allowing to
> use them anymore. There´re curves allowed in the BRs that Mozilla does not
> include. 
> 
> 2. Other un-revoked certificates have the same error “ ERROR: Unallowed key
> usage for EC public key (Key Encipherment) ”
> https://crt.sh/?opt=cablint=153404034
> https://crt.sh/?opt=cablint=160150786
> https://crt.sh/?opt=cablint=149445010
> https://crt.sh/?opt=cablint=150133570

Let’s break this down, as you have confused a few issues with this subset of 
the misissued certificates. Two certificates were issued with P-521 ECDSA keys, 
which is not allowed by Mozilla policy (note that P-384 keys are allowed):

- 
https://crt.sh/?q=87304EBF0F9391B8FFF7C8ED8D567F0340BCBAA6741972C030364DE5618C6757
- 
https://crt.sh/?q=962C955ABC03FC00F514EA41B2838D85826CA7CAA419A85EC186F1646AD5C9B5

Thirteen certificates (including the two P-521 certificates) were issued with 
the keyEncipherment bit set in the keyUsage extension (this is the message you 
mentioned above) which is not allowed (RFC 3279 section 2.3.5, incorporated by 
reference by RFC 5280 section 4.2.1.3, incorporated by reference by Baseline 
Requirements section 7.1.2.4).

One certificate linked above was issued without the key parameters field set, 
which is not allowed (RFC 3279 section 2.3.1, incorporated by reference by RFC 
5280 section 4.1.2.7, incorporated by reference by Baseline Requirements 
section 7.1.2.4):

- https://crt.sh/?opt=cablint=160150786

Hopefully this clarifies any misunderstandings around the problems with these 
specific certificates.

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Alex Gaynor via dev-security-policy]

Ouch. Thanks for clarifying.

Alex

On Thu, Aug 3, 2017 at 10:46 AM, Ben Wilson  wrote:

> There are over 300 publicly visible servers, according to Censys.IO.
>
>
>
> *From:* Alex Gaynor [mailto:agay...@mozilla.com]
> *Sent:* Thursday, August 3, 2017 8:42 AM
> *To:* Ben Wilson 
> *Cc:* Nick Lamb ; mozilla-dev-security-policy@
> lists.mozilla.org
>
> *Subject:* Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
>
>
> If I'm reading this correctly, these certificates are for internal
> services, not publicly accessible. Could they add their intermediate
> directly to these trust stores, allowing you to revoke it?
>
>
>
> Failing that, it sounds like OneCRL would be an appropriate remedy.
>
>
>
> Alex
>
>
>
> On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> Nick and Mozilla Community,
>
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:
>
> Good Evening Ben,
>
>About the problem with the certificate you recently notified us, I
> confirm you that we have replaced the certificates today, so we have now
> revoked the wrong one.
>
> Concerning the CA revocation, first of all, I want to underline that for us
> it would be a major issue: we don't have enough time and resources to
> replace all the certificates before the end of the year and the revocation
> of the CA will cause us several critical operating problems with our
> infrastructural services.
>
> Moreover, I would like to inform you that in order to rationalize our
> infrastructure and create new synergy between our suppliers, we've planned
> to move our certificates to an Italian CA outsourcer. We have already
> started this activity and our intent is to complete the migration before
> the
> end of the year, to respect the contract we have settled, with deadline
> December, 31st 2017.
>
> Therefore I have to kindly recommend you not to revoke the CA, before the
> end of the contract, because it will cause several problems to the Bank and
> to our users (customers and colleagues).
>
> We are available to set up a call conference with you to discuss the
> matter.
> Looking forward to hear from you.
>
> Best regards,
> Riccardo D'Agostini
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
>
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, August 3, 2017 7:33 AM
> To: Nick Lamb ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:34 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> > Nick,
> > We are in discussions with Intesa Sanpaolo about implementing/pursuing
> > OneCRL or a similar approach (e.g. outright revocation of the CAs).
> > Thanks,
> > Ben
>
> Is there any progress on this? To be honest I was more meaning that Mozilla
> (Gerv?) should just add this subCA to OneCRL and be done with it.
>
> ___
> 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
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

There are over 300 publicly visible servers, according to Censys.IO.



From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, August 3, 2017 8:42 AM
To: Ben Wilson 
Cc: Nick Lamb ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore 
intermediate



If I'm reading this correctly, these certificates are for internal services, 
not publicly accessible. Could they add their intermediate directly to these 
trust stores, allowing you to revoke it?



Failing that, it sounds like OneCRL would be an appropriate remedy.



Alex



On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy 
 > wrote:

Nick and Mozilla Community,

Here is the response from Intesa Sanpaolo concerning the disruption that
revocation will cause to their banking operations:

Good Evening Ben,

   About the problem with the certificate you recently notified us, I
confirm you that we have replaced the certificates today, so we have now
revoked the wrong one.

Concerning the CA revocation, first of all, I want to underline that for us
it would be a major issue: we don't have enough time and resources to
replace all the certificates before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

We are available to set up a call conference with you to discuss the matter.
Looking forward to hear from you.

Best regards,
Riccardo D'Agostini


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben 
 =digicert@lists.mozilla.org 
 ] On

Behalf Of Ben Wilson via dev-security-policy
Sent: Thursday, August 3, 2017 7:33 AM
To: Nick Lamb  >;
mozilla-dev-security-pol...@lists.mozilla.org 

Subject: RE: Certificate with invalid dnsName issued from Baltimore
intermediate

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben 
 =digicert@lists.mozilla.org 
 ] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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





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: Certificate with invalid dnsName issued from Baltimore intermediate

[Alex Gaynor via dev-security-policy]

If I'm reading this correctly, these certificates are for internal
services, not publicly accessible. Could they add their intermediate
directly to these trust stores, allowing you to revoke it?

Failing that, it sounds like OneCRL would be an appropriate remedy.

Alex

On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Nick and Mozilla Community,
>
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:
>
> Good Evening Ben,
>
>About the problem with the certificate you recently notified us, I
> confirm you that we have replaced the certificates today, so we have now
> revoked the wrong one.
>
> Concerning the CA revocation, first of all, I want to underline that for us
> it would be a major issue: we don't have enough time and resources to
> replace all the certificates before the end of the year and the revocation
> of the CA will cause us several critical operating problems with our
> infrastructural services.
>
> Moreover, I would like to inform you that in order to rationalize our
> infrastructure and create new synergy between our suppliers, we've planned
> to move our certificates to an Italian CA outsourcer. We have already
> started this activity and our intent is to complete the migration before
> the
> end of the year, to respect the contract we have settled, with deadline
> December, 31st 2017.
>
> Therefore I have to kindly recommend you not to revoke the CA, before the
> end of the contract, because it will cause several problems to the Bank and
> to our users (customers and colleagues).
>
> We are available to set up a call conference with you to discuss the
> matter.
> Looking forward to hear from you.
>
> Best regards,
> Riccardo D'Agostini
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, August 3, 2017 7:33 AM
> To: Nick Lamb ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:34 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> > Nick,
> > We are in discussions with Intesa Sanpaolo about implementing/pursuing
> > OneCRL or a similar approach (e.g. outright revocation of the CAs).
> > Thanks,
> > Ben
>
> Is there any progress on this? To be honest I was more meaning that Mozilla
> (Gerv?) should just add this subCA to OneCRL and be done with it.
>
> ___
> 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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Nick and Mozilla Community,

Here is the response from Intesa Sanpaolo concerning the disruption that
revocation will cause to their banking operations:

Good Evening Ben,

   About the problem with the certificate you recently notified us, I
confirm you that we have replaced the certificates today, so we have now
revoked the wrong one.

Concerning the CA revocation, first of all, I want to underline that for us
it would be a major issue: we don't have enough time and resources to
replace all the certificates before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

We are available to set up a call conference with you to discuss the matter.
Looking forward to hear from you.

Best regards,
Riccardo D'Agostini


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Ben Wilson via dev-security-policy
Sent: Thursday, August 3, 2017 7:33 AM
To: Nick Lamb ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Certificate with invalid dnsName issued from Baltimore
intermediate

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing 
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing 
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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: StartCom cross-signs disclosed by Certinomis

[Alex Gaynor via dev-security-policy]

From RFC6962:

The signature on the TBSCertificate indicates the certificate
authority's intent to issue a certificate.  This intent is considered
binding (i.e., misissuance of the Precertificate is considered equal
to misissuance of the final certificate).

I don't think this text could be any more clear, and I'm frankly
astounded that any CA would try to argue they shouldn't be held to
account for them.

If you wouldn't issue a cert, don't issue the pre-cert. It's really that simple.


Alex


On Thu, Aug 3, 2017 at 7:20 AM, Inigo Barreira via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We´re revoking all those unrevoked certs to avoid any more problems.
>
> Regarding the pre-certs, yes, I was aware of the discussion. As Gerv says
> there´s a binding statement of "intent" ... the problem with these is that
> we generated the pre-certs and logged in the CT log, where crt.sh looks or
> monitor, but those weren´t finally issued, so there are not such certs.
> In any case, as said, we´re revoking all of those listed and will update
> the
> bugzilla accordingly
>
> Best regards
>
> Iñigo Barreira
> CEO
> StartCom CA Limited
>
> -Original Message-
> From: Patrick Figel [mailto:patrick@figel.email]
> Sent: jueves, 3 de agosto de 2017 13:07
> To: Inigo Barreira ; Franck Leroy
> ; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: StartCom cross-signs disclosed by Certinomis
>
> On 03/08/2017 10:47, Inigo Barreira via dev-security-policy wrote> 1.
> The un-revoked test certificates are those pre-sign ones with uncompleted
> > ctlog. So they are not completed certificates.
> > https://crt.sh/?opt=cablint=134843670
> > https://crt.sh/?opt=cablint=134843674
> > https://crt.sh/?opt=cablint=134843685
> > https://crt.sh/?opt=cablint=139640371
>
> My understanding of Mozilla's policy is that misissued precerts are
> considered misissuance nonetheless[1].
>
> [1]:
> https://groups.google.com/d/msg/mozilla.dev.security.
> policy/6pBLHJBFNts/kM3k
> EJKMAgAJ
>
> ___
> 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: DigiCert-Symantec Announcement

[Alex Gaynor via dev-security-policy]

Hi Jeremy,

Will the certificates being issued for Symantec starting December 1st be
issued under the existing DC roots, or under new roots?

Alex

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi everyone,
>
>
>
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017.  We are
> committed to meeting the Mozilla and Google plans in transitioning away
> from
> the Symantec infrastructure. The deal is expected to close near the end of
> the year, after which we will be solely responsible for operation of the
> CA.
> From there, we will migrate customers and systems as necessary to
> consolidate platforms and operations while continuing to run all issuance
> and validation through DigiCert.  We will post updates and plans to the
> community as things change and progress.
>
>
>
> I wanted to post to the Mozilla dev list to:
>
> 1.  Inform the public,
> 2.  Get community feedback about the transition and concerns, and
> 3.  Get an update from the browsers on what this means for the plan,
> noting that we fully commit to the stated deadlines. We're hoping that any
> changes
>
>
>
> Two things I can say we plan on doing (following closing) to address
> concerns are:
>
> a.  We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from
> different roots. We also plan on limiting the number of organizations on
> each issuing CA.  We hope this will help address the "too big to fail"
> issue
> seen with Symantec.  By segregating end entities into roots and sub CAs,
> the
> browsers can add affected Sub CAs to their CRL lists quickly and without
> impacting the entire ecosystem.  This plan is very much in flux, and we'd
> love to hear additional recommendations.
> b.  Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to issue the
> cert. This way the entire community can readily identify which method was
> used when issuing a cert and take action if a method is deemed weak or
> insufficient.  We think this is a huge improvement over the existing
> landscape, and I'm very excited to see that OID rolled out.
>
>
>
> Thanks a ton for any thoughts you offer.
>
>
>
> Jeremy
>
>
> ___
> 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: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

We´re revoking all those unrevoked certs to avoid any more problems.

Regarding the pre-certs, yes, I was aware of the discussion. As Gerv says
there´s a binding statement of "intent" ... the problem with these is that
we generated the pre-certs and logged in the CT log, where crt.sh looks or
monitor, but those weren´t finally issued, so there are not such certs.
In any case, as said, we´re revoking all of those listed and will update the
bugzilla accordingly

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: Patrick Figel [mailto:patrick@figel.email] 
Sent: jueves, 3 de agosto de 2017 13:07
To: Inigo Barreira ; Franck Leroy
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On 03/08/2017 10:47, Inigo Barreira via dev-security-policy wrote> 1.
The un-revoked test certificates are those pre-sign ones with uncompleted
> ctlog. So they are not completed certificates.
> https://crt.sh/?opt=cablint=134843670
> https://crt.sh/?opt=cablint=134843674
> https://crt.sh/?opt=cablint=134843685
> https://crt.sh/?opt=cablint=139640371

My understanding of Mozilla's policy is that misissued precerts are
considered misissuance nonetheless[1].

[1]:
https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/kM3k
EJKMAgAJ


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: StartCom cross-signs disclosed by Certinomis

[Nick Lamb via dev-security-policy]

1. It is well established that logging pre-certs constitutes "issuance" for 
purposes of policy compliance. If you wouldn't issue it, don't log it. Not 
difficult. And this isn't new.

2. When a new path comes into existence in the Web PKI you don't need to 
explicitly "use" it as a CA, the Relying Parties may rely on this path for a 
variety of reasons out of your control. If you don't want a particular path to 
be used don't create it.

(An example not related to the present circumstances: Let's Encrypt has a path 
from their Issuing CAs to the ISRG root. Today this root is not widely trusted 
and so they provide subscribers with an alternative intermediate CA cert 
leading to Identrust. But some clients, including Firefox, will use the ISRG 
path anyway because they trust it.)

3. The non-disclosure of the CA:TRUE certs is unambiguously a policy violation. 
Adding them to OneCRL immediately seems like exactly the right response.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Patrick Figel via dev-security-policy]

On 03/08/2017 10:47, Inigo Barreira via dev-security-policy wrote> 1.
The un-revoked test certificates are those pre-sign ones with uncompleted
> ctlog. So they are not completed certificates.
> https://crt.sh/?opt=cablint=134843670
> https://crt.sh/?opt=cablint=134843674
> https://crt.sh/?opt=cablint=134843685
> https://crt.sh/?opt=cablint=139640371

My understanding of Mozilla's policy is that misissued precerts are
considered misissuance nonetheless[1].

[1]:
https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/kM3kEJKMAgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Hi, this is my reply in the bugzilla


Hi all,

what Fanck is saying is true and we haven´t started to issue any cert using
this new path. 

Regarding the info that is in this bug I´m really shocked because the
majority of them are revoked and don´t understand why have been included
here. 


For those which are not revoked are due to use different curves (P-384,
P-521) that have been discussed in the mozilla m.d.s.p as well as the CAB
Forum and there´s no conclusion yet, but in any case we´re not allowing to
use them anymore. There´re curves allowed in the BRs that Mozilla does not
include. 

1. The un-revoked test certificates are those pre-sign ones with uncompleted
ctlog. So they are not completed certificates.
https://crt.sh/?opt=cablint=134843670
https://crt.sh/?opt=cablint=134843674
https://crt.sh/?opt=cablint=134843685
https://crt.sh/?opt=cablint=139640371

2. Other un-revoked certificates have the same error “ ERROR: Unallowed key
usage for EC public key (Key Encipherment) ”
https://crt.sh/?opt=cablint=153404034
https://crt.sh/?opt=cablint=160150786
https://crt.sh/?opt=cablint=149445010
https://crt.sh/?opt=cablint=150133570


And what I don´t understand are those comments of "very sloppy isuance
practices" , "many non-BR compliants", "specially given the historic issues
with StartCom" and consider them very unfair. These are subjective opinions
which are very dangerous and not fair. 
This is a totally new system that is not related with "the historic issues"
at all, so whatever happened in the past is not related (and we could talk a
lot of why StartCom was distrusted in the past), only the name is the same.
Some of the issues are also related what has been discussing in the CABF
related to the Unicode and punnycode in domanins, etc. and even there´s no
conclussion as the ballot failed, we decided to revoke those to avoid issues
but you include them here as non BR compliants and very sloppy issuance
practices.

Finally I´d like to understand also why has been asked to create OneCRL
entries for these subCAs.

I may think this post and some other comments in the m.d.s.p are malicious
and don´t know why.

Regards

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Franck Leroy via dev-security-policy
Sent: jueves, 3 de agosto de 2017 9:59
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

Hello,

the 2 CA certificates signed by Certinomis has been retained till a full
successful webtrust audit.

On end of June the audit report form PwC was available but with still some
minor issues. I asked StartCom to correct them.

On July 14th the audit report and the policy were updated and published on
StartCom website.

The first of August I received the agreement from my management to send the
CA certificates to StartCom. So I disclose them in the CCADB, with the
corresponding policy documents and audit reports before sending them to
Inigo.

So StartCom was not able to use the path our Root before yesterday.

If there are some previous issued TLS certificates that does not comply with
BR, then theses TLS certificates has to be revoked.

Best regards
Franck Leroy
___
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: StartCom cross-signs disclosed by Certinomis

[Franck Leroy via dev-security-policy]

Hello,

the 2 CA certificates signed by Certinomis has been retained till a full 
successful webtrust audit.

On end of June the audit report form PwC was available but with still some 
minor issues. I asked StartCom to correct them.

On July 14th the audit report and the policy were updated and published on 
StartCom website.

The first of August I received the agreement from my management to send the CA 
certificates to StartCom. So I disclose them in the CCADB, with the 
corresponding policy documents and audit reports before sending them to Inigo.

So StartCom was not able to use the path our Root before yesterday.

If there are some previous issued TLS certificates that does not comply with 
BR, then theses TLS certificates has to be revoked.

Best regards
Franck Leroy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Olfa Kaddachi via dev-security-policy]

Dear Gerv,
Given that some of these are BR requirements, why were these controls not in 
place already? 
==> Some of these controls are already in place (such as the field CN and 
Subject Alternative Name that does not contain a private IP address). 
In addition to that NDCA has implemented a procedure for the RA operators which 
include these sections:
1-  Validation of the Organization  

-   In case of a commercial  and private organization: The RA operator 
checks the web site http://www.registre-commerce.tn. Then, he inserts the Tax 
Identification Number to verify the existence of the organization.

-   In the case of a public organization : The RA operator checks the web 
site http://www.infojort.com. Then, he inserts the Tax Identification Number to 
verify the existence of the organization.
2-  Domain Validation :
For the National domains, the RA operator checks the web site of the Tunisian 
Internet Agency which is responsible of the management of the national domain 
".tn" and the IP addressing in Tunisia ( http://whois.ati.tn ).
For the international domains, the RA operator checks the international whois.
In both cases, the RA operator checks if the domain name is the property of the 
applicant.
3-  CSR Validation
The RA operator checks the CSR with this URL  
https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp





4-  Validation of the technical data included in the CSR: The RA operator 
checks :

Digital Signature Algorithm: SHA256
Key Algorithm: RSA
Key Size: 2048

5-  Validation of the data inserted in the CSR against the data filled in 
the form  :
Common name:
Organization:
Organizational unit:
City/locality:
State/province:
Country:
6-  Validation of the email : The RA operator checks if the email is in 
this form:
ad...@domaine.com
postmas...@domaine.com
administra...@domaine.com
webmas...@domaine.com
7-  Validation of the information related to the legal person and the 
subscriber  
8-  Phone Call to the webmaster of the server
Moreover, the NDCA is now implementing a new Managed PKI platform which will be 
in production by the end of September 2017.  For the moment, the only 
improvement done, is the printing of all the subject alternative names in the 
certificate for the RA operators, in addition to the other fields (CN, O, OU, 
mail) in such a way that they can visually check all the fields before the 
delivery of the certificate.

From what date would you say that your CA has been compliant with the CAB Forum 
Baseline Requirements? 
==> The TunRootCA2 and TunServerCA2 passed two successive external audit 
performed by LSTI. The last audit took place from 27th to 30th September 2016 
in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1. 
The audit was performed by LSTI as a full audit. This audit confirms the 
validity of the certificate N° 11140 issued on November 2015 and valid until 
November 2018. The next full audit will be performed from 11th to 15th of 
September 2017.

When will these improvements be implemented? And, given that these are only 
four possible ways a certificate can be messed up, what other checks are going 
to be implemented at the same time? 
==> These improvements have already been implemented by our service provider 
during this week. The tests will be done from 14th to 25th of August 2017.  The 
beginning of production is planned for the end of September after the audit.
We already have other checks besides those four in our information system such 
as checking the fields in the CSR. These checks are already implemented.
Olfa
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 3 August 2017 02:12:18 UTC+2, Matt Palmer  wrote:
> On Wed, Aug 02, 2017 at 06:38:44PM -0400, Jonathan Rudenberg via 
> dev-security-policy wrote:
> > I think the correct response is to add both intermediates to OneCRL
> > immediately, especially given the historic issues with StartCom.
> 
> +1.  Also a strongly worded letter of "are you f%*king kidding me?!?" to
> Certinomis.  Everyone even ephemerally involved in the WebPKI should know by
> now that StartCom/WoSign are viewed with deep suspicion, and blithely
> signing an intermediate for them is not a smart move.
> 
> - Matt

It just means Certinomis now has to answer for the misissuance, doesn't it? I 
don't see the problem. They can choose to risk their own webtrust if they want 
to. ;-)

CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy