Re: Pre-Incident Report - WISeKey Serial Number Entropy

[Wayne Thayer via dev-security-policy]

Pedro,

Thank you for reporting this issue.

On Tue, Mar 19, 2019 at 2:10 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> In light of the recent discussion related to serial number Entropy, at
> WISeKey we could verify that we were also affected by this issue. We are
> still doing the final investigation, but I'd like to open this thread to
> initiate the disclosure. I'll do the same opening a bug.
>
>
I was not able to locate an associated bug, so I have just created
https://bugzilla.mozilla.org/show_bug.cgi?id=1540281 to track this issue.

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

Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

[Wayne Thayer via dev-security-policy]

The BRs require EKUs in leaf TLS certs, but there is no equivalent
requirement for S/MIME certificates. This leads to confusion such as [1] in
which certificates that are not intended for TLS or S/MIME fall within the
scope of our policies.

Simply requiring EKUs in S/MIME certificates won't solve the problem unless
we are willing to exempt certificates without an EKU from our policies, and
doing that would create a rather obvious loophole for issuing S/MIME
certificates that don't adhere to our policies.

The proposed solution is to require EKUs in all certificates that chain up
to roots in our program, starting on some future effective date (e.g. April
1, 2020). This has the potential to cause some compatibility problems that
would be difficult to measure and assess. Before drafting language for this
proposal, I would like to gauge everyone's support for this proposal.

Alternately, we could easily argue that section 1.1 of our existing policy
already makes it clear that CAs must include EKUs other than
id-kp-serverAuth and id-kp-emailProtection in certificates that they wish
to remain out of scope for our policies.

This is https://github.com/mozilla/pkipolicy/issues/163

I will greatly appreciate everyone's input on this topic.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi  wrote:

>
> On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer  wrote:
>
>> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi  wrote:
>>
>>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
 **Incidents**
 > When a CA fails to comply with any requirement of this policy -
 whether it
 > be a misissuance, a procedural or operational issue, or any other
 variety
 > of non-compliance - the event is classified as an incident. At a
 minimum,
 > CAs MUST promptly report all incidents to Mozilla in the form of an
 Incident
 > Report , and
 MUST
 > regularly update the Incident Report until the corresponding bug is
 > resolved by a Mozilla representative. In the case of misissuance, CAs
 > SHOULD cease issuance until the problem has been prevented from
 reoccurring.

>>> For comparison, Microsoft's policy is
>>> https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident
>>>
>> Thanks for the reference. I would note that Microsoft's requirements
>> appear to be much narrower in scope, applying to "Security Incidents" as
>> defined in section 6. Having said that, are there specific requirements
>> that we should consider adding to Mozilla policy?
>>
>
> There are two things that stand out to me that are unclear if you meant to
> incorporate by reference to the incident report:
> - Whether it's a policy violation if the CA fails to disclose the affected
> certificates, which MSFT policy explicitly requires
>


We would only want this if the certificates were disclosed publicly, and
that seems challenging. TLS certs will, of course, be logged because of
other UA's requirements, but for email certs CAs may not have the
contractual right to disclose publicly. And "GDPR".

- What, if any, timeframe for periodic updates. MSFT policy explicitly
> states that MSFT shall determine the update cadence. (This may be a
> non-issue)
>
>
Conceptually this makes sense, but I would be interested to hear your
thoughts on what our requirement should be? A one-size-fits-all requirement
of something like weekly updates could be an enforcement nightmare. We
already assume the right to set deadlines for responses, so it's not
obvious to me what we'd want in this requirement.

Additionally, in further consideration of both this proposal and the
> highlighted difference, it's unclear whether it's intended to create a
> hierarchy of incidents. I think the language, as worded, does - perhaps
> inadvertantly - by mentioning misissuance vs a procedural or operational
> issue.
>
> Consider, for example, a CA that determines they're copying the O field
> directly from CSRs into the final certificates. Such certificates are
> unquestionably misissued, but the language creates the opportunity that the
> CA would argue it's a "procedural or operational" issue, and thus they're
> not required to cease issuance until the problem has been prevented.
>


This language was cribbed from the wiki page: "In misussuance cases, a CA
should almost always immediately cease issuance from the affected part of
your PKI until you have diagnosed the source of the problem, or explain why
this has not been done"

Perhaps it shouldn't try to account for things like OCSP misconfiguration
and only state: "CAs SHOULD cease issuance until the problem has been
prevented from reoccurring."?


>
> One thing to consider with such a policy is whether to formalize the use
>>> of Bugzilla to track these. In looking through incident reports that have
>>> been filed, we see a fair distribution between the initial reporting being
>>> on the email list vs Bugzilla. We've certainly seen Bugzilla be more useful
>>> in tracking unacknowledged questions and responses (via the use of
>>> Needs-Info). Would it make sense to require that the incident report be
>>> provided via Bugzilla, with a notification to the mail list?
>>>
>>
>> I would be interested in everyone's opinion on this. While I agree that
>> Bugzilla is a necessary mechanism for tracking incidents, I believe that it
>> reduces community visibility and makes it more difficult for most members
>> to follow incident discussions. It has been suggested that we create a
>> process that automatically publishes a summary of new or updated incident
>> bugs to this list on a periodic basis, but that obviously isn't yet in
>> place. Even with that, I might argue that the requirement should be to
>> publish incident reports to m.d.s.p., with a bug then being created by the
>> CA or a Mozilla representative.
>>
>
> I do share those concerns, hence the attempt to split it in the middle.
>
> My concern is that there have been several high-profile incidents which
> have been discussed in m.d.s.p., in which very relevant questions from
> members of the community go ignored, perhaps deliberately, and it b

Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"

[Wayne Thayer via dev-security-policy]

On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 28/03/2019 21:52, Wayne Thayer wrote:
> > Our current Root Store policy assigns two different meanings to the term
> > "technically constrained":
> > * in sections 1.1 and 3.1, it means 'limited by EKU'
> > * in section 5.3 it means 'limited by EKU and name constraints'
> >
> > The BRs already define a "Technically Constrained Subordinate CA
> > Certificate" as:
> >
> > A Subordinate CA certificate which uses a combination of Extended Key
> Usage
> >> settings and Name Constraint settings to limit the scope within which
> the
> >> Subordinate CA Certificate may issue Subscriber or additional
> Subordinate
> >> CA Certificates.
> >>
> >
> > I propose aligning Mozilla policy with this definition by leaving
> > "technically constrained" in section 5.3, and changing "technically
> > constrained" in sections 1.1 and 3.1 to "technically capable of issuing"
> > (language we already use in section 3.1.2). Here are the proposed
> changes:
> >
> >
> https://github.com/mozilla/pkipolicy/commit/91fe7abdc5548b4d9a56f429e04975560163ce3c
> >
> > This is https://github.com/mozilla/pkipolicy/issues/159
> >
> > I will appreciate everyone's comments on this proposal. In particular,
> > please consider if the change from "Such technical constraints could
> > consist of either:" to "Intermediate certificates that are not considered
> > to be technically capable will contain either:" will cause confusion.
> >
>
> To further reduce confusion, perhaps change the terminology in Mozilla
> policy to "Technically Constrained to Subscriber", meaning technically
> constrained to only be capable of issuing for a fully validated
> subscriber identity (validated as if some hypothetical kind of wildcard
> EE cert).
>
>
I think that "Technically Constrained to Subscriber" is more confusing and
not necessarily accurate in the case where the Subscriber is in control of,
but not the same as one of more of the permitted domain names, IP
addresses, or email addresses.

This of cause remains applicable to all the kinds of identities
> recognized and regulated by the Mozilla root program, which currently
> happens to be server domain, EV organization, and e-mail address
> identities.
>
> I realize that the BR meaning may be intended to be so too, but many
> discussions over the years have indicated confusion.
>
>
Can you provide an example of the confusion that this additional change
would help to clarify?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Pre-Incident report: PKIoverheid Serial Number Entropy

[Berge, J. van den (Jochem) - Logius via dev-security-policy]

Dear MDSP community, 

We would like to share an update to our initial post-mortem of 03/13/2019
and our subsequent updates of 03/19/2019 and 03/22/2019

Following the discussions on MDSP Logius has determined that the following
G3 TSP CA’s (Issuing CA certificates) are not compliant with BR 7.1 and/or
the current valid section of the Mozilla CA Policy and will therefore be
replaced within 2 months:

Cleverbase ID PKIoverheid Burger CA - G3; Digidentity BV PKIoverheid
Organisatie Persoon CA - G3; Digidentity BV PKIoverheid Organisatie Server
CA - G3; Digidentity BV PKIoverheid Burger CA - G3; KPN BV PKIoverheid
Organisatie Server CA - G3; MinIenW PKIoverheid Organisatie Services CA -
G3; MinIenW PKIoverheid Organisatie Persoon CA - G3; QuoVadis PKIoverheid
Organisatie Server CA - G3; UZI-register Medewerker op naam CA G3;
UZI-register Zorgverlener CA G3; UZI-register Medewerker niet op naam CA G3.

The TSP CAs in question will be replaced by CAs with a serial number length
of 128 bits or higher. 

The following roadmap will be used for remediation of the end user
certificates as outlined in our previous post: 
•   KPN has already switched to serial numbers with a 96-bit length on
March 5. New certificates issued by them after this date are not affected.
Of the 22.000 TLS certificates in scope ~3900 have been marked as being in
use for browser use cases (websites e.g.) and will be replaced after the new
issuing CA has been brought into operation. The replacement of the TLS
certificates will take 6 months so the total replacement will take 8 months.
The remainder of the certificates (~18K) will be regularly (re)checked to
confirm that they are in use for private systems and machine-to-machine
traffic. They will be replaced by compliant or private SSL certificates when
possible. 
•   Logius has decided not to replace the TLS certificates issued by
CIBG as these ~4500 certificates will expire before the end of March 2020
and will automatically be replaced by private certificates. 
The following roadmap will be used for S/MIME certificates as outlined in
our previous post:
•   We will let the current S/MIME certificates expire. 
All other end-user certificates issued by PKIoverheid have a serial number
of sufficient length.

In addition, we have formulated the following new measures to ensure this
particular type of issue will not be repeated in the future and which will
improve the resilience of our PKI setup:

Technical constraints/use of Private CAs
PKIoverheid has found that for certain types of use, the supplied types of
certificates could be technically restrained without affecting its intended
use. We will further research this area and will strive to technically
restrain EE certificates as much as possible. 

Increase in technical monitoring/oversight
PKIoverheid runs a program called VTT (verbeterd technisch toezicht;
“improved techical supervision”) which closely follows developing industry
practices concerning technical oversight tooling (e.g. linting tools). We
will increase resources for this program to enhance our insight into the
quality of certificates issued within the PKIoverheid scope and as such
catch potential issues earlier.

Self-service (re)provisioning/automated issuance
Although we cannot control how end users implement the certificates issued
by PKIoverheid TSPs, we think it prudent to distribute PKI implementation
best practises for end-users, using newly developed or existing self-service
(re)provisioning tooling.

Regards,

Jochem 

-Oorspronkelijk bericht-
Van: dev-security-policy 
Namens Berge, J. van den (Jochem) - Logius via dev-security-policy
Verzonden: vrijdag 22 maart 2019 16:16
Aan: mozilla-dev-security-pol...@lists.mozilla.org
Onderwerp: RE: Pre-Incident report: PKIoverheid Serial Number Entropy

Dear MDSP community,

Firstly our apologies for the delay in our follow-up response. A joint
analysis of the 64-bit serial issue by Logius and its TSPs took more time
than expected. We would like to share an update to our initial post-mortem
of 03/13/2019 and our subsequent update of 03/19/2019.

In close consultation with Dutch CERT (NCSC) and the politically and
administratively responsible officials of the Dutch Ministry of Interior
Affairs and Kingdom Relations we have conceived the following blueprint:
 
We’ve formulated the following starting points:
1.  The effort involved in replacing the end-user S/MIME certificates is
severe plus almost half of them will expire and be replaced in the coming
year by either private certificates or newly issued certificates which
comply with the Mozilla CA policy section 5.2.   
2.  Replacing non-compliant end-user certificates issued by a TSP CA
which needs to be replaced involves a lot of rework. First course of action
should be to replace the issuing (TSP) CAs.
3.  We consider compliant end-user certificates issued by a
non-compliant TSP CA to be compliant. The non-compliant issuing TSP CA will
need to be

Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"

[Jakob Bohm via dev-security-policy]

On 28/03/2019 21:52, Wayne Thayer wrote:
> Our current Root Store policy assigns two different meanings to the term
> "technically constrained":
> * in sections 1.1 and 3.1, it means 'limited by EKU'
> * in section 5.3 it means 'limited by EKU and name constraints'
> 
> The BRs already define a "Technically Constrained Subordinate CA
> Certificate" as:
> 
> A Subordinate CA certificate which uses a combination of Extended Key Usage
>> settings and Name Constraint settings to limit the scope within which the
>> Subordinate CA Certificate may issue Subscriber or additional Subordinate
>> CA Certificates.
>>
> 
> I propose aligning Mozilla policy with this definition by leaving
> "technically constrained" in section 5.3, and changing "technically
> constrained" in sections 1.1 and 3.1 to "technically capable of issuing"
> (language we already use in section 3.1.2). Here are the proposed changes:
> 
> https://github.com/mozilla/pkipolicy/commit/91fe7abdc5548b4d9a56f429e04975560163ce3c
> 
> This is https://github.com/mozilla/pkipolicy/issues/159
> 
> I will appreciate everyone's comments on this proposal. In particular,
> please consider if the change from "Such technical constraints could
> consist of either:" to "Intermediate certificates that are not considered
> to be technically capable will contain either:" will cause confusion.
> 

To further reduce confusion, perhaps change the terminology in Mozilla 
policy to "Technically Constrained to Subscriber", meaning technically 
constrained to only be capable of issuing for a fully validated 
subscriber identity (validated as if some hypothetical kind of wildcard 
EE cert).

This of cause remains applicable to all the kinds of identities 
recognized and regulated by the Mozilla root program, which currently 
happens to be server domain, EV organization, and e-mail address 
identities.

I realize that the BR meaning may be intended to be so too, but many 
discussions over the years have indicated confusion.



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: Clarify Meaning of "Technically Constrained"

[Pedro Fuentes via dev-security-policy]

Hello,
related to this... I'd like to point out something that is bugging me...

Section 7.1.5 of the BR stipulates...

First paragraph: "For a Subordinate CA Certificate to be considered Technically 
Constrained..."

Second paragraph: "If the Subordinate CA Certificate includes the 
id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST 
include the Name Constraint..."

An strict reading of these two paragraphs would drive to the consequence that 
if the EKU exist, then the name constraint MUST be there too. It's evident that 
this is intended for a CA to be considered as technically constrained, but I 
think it can lead to an incompatibility with the Mozilla Policy, that expects 
all issuing CAs to include the EKU constraint since 1/1/2019

Maybe my comment is irrelevant, but as said, it was unsettling me.

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