CCADB System Upgrades October 15, 8am-6pm Pacific Time

2018-10-09 Thread Kathleen Wilson via dev-security-policy

All,

We will be doing system upgrades to the CCADB on Monday, October 15, 
8am-6pm Pacific Time. There will be limited functionality during that time.


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


Re: Yet more undisclosed intermediates

2018-10-09 Thread Wayne Thayer via dev-security-policy
Thank you Rob.

On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> "ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs
> of the Mozilla Root Store Policy requirement [2] that
> non-technically-constrained intermediate CA certificates...
>"MUST be publicly disclosed in the CCADB by the CA that has their
> certificate included in Mozilla's root program. The CA with a
> certificate included in Mozilla's root program MUST disclose this
> information within a week of certificate creation, and before any
> such subordinate CA is allowed to issue certificates."
>
> In their responses to "ACTION 6" [3], most CAs indicated that...
>"We are aware of the requirements for intermediate certificate
> disclosure and have processes in place to ensure that these
> requirements are met"
>
>  In fact, every CA  except Trustis (no longer issuing certificates) and
Certicamara (still hasn't responded) indicated that they comply with this
policy.

There are currently 20 undisclosed non-technically-constrained
> intermediates, belonging to 6 Root Owners, on "Rob's naughty list" [4]
> (snapshot at [5]).  All 20 were undisclosed and listed (on [4]) on the
> day the responses to [1] were due (September 30th), which means that
> they have not been disclosed "within a week of certificate creation".
>
> So, ISTM that the "processes in place to ensure that these requirements
> are met" are insufficient/broken for at least the following Root Owners:
>- Certicámara
>

These are the same four that I reported to Certicamara back in April via
https://bugzilla.mozilla.org/show_bug.cgi?id=1455128 I emailed them
yesterday about this and their failure to respond to the September CA
Communication.

   - DigiCert
>

Looks like DigiCert disclosed these within a few hours of your email.

   - DocuSign (OpenTrust/Keynectis)
>

 I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1497700

   - SECOM Trust Systems CO., LTD.
>- SwissSign AG
>

This is incredibly disappointing given
https://bugzilla.mozilla.org/show_bug.cgi?id=1455132 (among other recent
SwissSign issues)

   - Telia Company (formerly TeliaSonera)
>
> I reopened https://bugzilla.mozilla.org/show_bug.cgi?id=1451953 This is
also disappointing given Telia's other recent issues.

Wayne, Kathleen:
> Given the number of times that all the CAs in Mozilla's Root Program
> have been reminded about Mozilla's requirements for disclosing
> intermediate certs, I wouldn't blame you if you decided to add these 20
> intermediate certs [5] to OneCRL immediately!
>
>
I think we should give this serious consideration, although it doesn't help
with the majority of these that are trusted for email.

>
> [1]
>
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3rMGLL
>
> [2]
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited
>
> [3]
>
> https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3rMGLL=Q00078,Q00079
>
> [4] https://crt.sh/mozilla-disclosures#undisclosed
>
> [5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Odp.: 46 Certificates issued with BR violations (KIR)

2018-10-09 Thread Wayne Thayer via dev-security-policy
On Tue, Oct 9, 2018 at 5:30 AM Grabowski Piotr 
wrote:

> Hello Wayne,
>
> Please find our comments below:
>
>
> So far the process for modifying policy templates was controlled by only
> one person at the moment. Although these persons
> have an extensive experience in PKI and preparing certificate templates
> and in common daily duties they work with serveral CA's and with hundreds
> of templates and it was the first (and we hope the last) time
> that something was misconfigured . This incident showed us that this
> process should be definitely changed and that's why practicing due care
> we are updating remediation steps or plan for:
>
> 1. Reviewed all certificate policy templates for ensuring that all of them
> are BR comliant.  /done
> 2. All the certificates owners were contacted and agreed on issuance new
> BR compliant certificates in time convenient for them, preferably not later
> than by  the end of this year and revocation current ones. /done
> 3. Added procedural step for periodic certificate policy templates
> validation. /done
>
> 4. Implement dual CAO control for modifying policy template which requires
> the presence of 2 CAO's (Certification Authority Operators)  /done
> 5. CAO audit logs will be daily scanned by system Auditor for policy
> change events and comapared if they match events from point 4) /done
> 6. Implement pre-issuance linting - we have sent request, *urgent need*
> to our PKI software vendor about delivery this functionality.
> If we know the timeframe we will update this report.
>
> Do you think it is a sufficient response to incident?
>

I do appreciate your prompt response, but #4 in particular strikes me as an
inadequate quick fix lacking any plan to make a concerted effort to learn
from this mistake.

- Is the new dual control process documented in a manner that will be
auditable by your external auditors?
- How is version control maintained for policy templates?
- Despite the review, is it possible for one malicious employee to modify a
policy template by themselves? If not, why not?
- Have you conducted an overall review of your practices looking for other
areas where a human error can result in misissuance? If so, what did you
find and how are you addressing it?
- Why, despite the numerous misissuances documented on this list, has KIR
not even begun the process of implementing pre-issuance linting until now?
- Why is KIR not performing post-issuance linting? This problem had been
occurring for over a year and there are readily available tools (
https://crt.sh) that allow anyone to identify these problems.

Also, please respond to Ryan's email questioning how this happened.

- Wayne

>
>
>
>
Best Reagrds
> Piotr Grabowski
> --
> *Od:* Wayne Thayer 
> *Wysłane:* poniedziałek, 8 października 2018 19:13:46
> *Do:* Grabowski Piotr
> *DW:* mozilla-dev-security-policy
> *Temat:* Re: 46 Certificates issued with BR violations (KIR)
>
> Thank you for the incident report. I have posted it to the bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1495497
>
> On Mon, Oct 8, 2018 at 8:25 AM piotr.grabowski--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Here's the incident report:
>>
>> 1.How your CA first became aware of the problem (e.g. via a problem
>> report submitted to your Problem Reporting Mechanism, via a
>>
>> discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and
>> the date.
>>
>> Email from Wayne Thayer Oct 1, 2018
>>
>> 2.A timeline of the actions your CA took in response.
>>
>> A. Oct 2, 2018 - Investigation began.
>> B. Oct 4, 2018 - Found impacted certificate policy templates.
>> C  Oct 4, 2018 - All the certificates owners were contacted and agreed on
>> issuance new BR compliant certificates in time convenient for them,
>>   preferably not later than by the end of this year and revocation
>> current ones.
>> D. Oct 8, 2018 - Fixed impacted certificate policy templates.
>> E. Oct 8, 2018 - This disclosure.
>>
>> Ongoing:
>> F. Replacement of impacted certificates
>> G. Training of periodic certificate policy templates validation.
>>
>> 3.Confirmation that your CA has stopped issuing TLS/SSL certificates
>> with the problem.
>>
>> Confirmed.
>>
>> 4.A summary of the problematic certificates. For each problem: number
>> of certs, and the date the first and last certs with that problem
>>
>> were issued.
>>
>> There are 46 certificates.  The certificates were issued between Feb 20,
>> 2017 and Sep 25, 2018.
>>
>> 5.The complete certificate data for the problematic certificates. The
>> recommended way to provide this is to ensure each certificate is
>>
>> logged to CT and then list the fingerprints or crt.sh IDs, either in the
>> report or as an attached spreadsheet, with one list per distinct
>> problem.
>>
>> Added as attachment
>>
>> https://crt.sh/?caid=15985=cablint,zlint,x509lint=2017-01-01
>>
>> 6.Explanation about how and why the 

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

2018-10-09 Thread Wayne Thayer via dev-security-policy
On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Oh, so rather than trying to define what "No Stipulation" means and when
> it can be used, we could take a different approach -- list the sections
> that cannot contain "No Stipulation" in the CPS.
>
> This approach implies that we are adopting the RFC 3647 definition of "no
stipulation" meaning "we can do whatever we want", not the meaning of "we
don't do this" that I believe is intended in the examples your provided. If
we take this approach, we should specify those section that **must be
present** and cannot contain "no stipulation" (or similar permissive
language). Omitting a section defined in RFC 3647 is equivalent to "no
stipulation".


> On 10/9/18 12:31 PM, Brown, Wendy (10421) wrote:
> > Tim  -
> >
> > I think that statement leaves out the next paragraph of RFC3647:
> > In a CP, it is possible to leave certain components, subcomponents,
> and/or elements unspecified, and to stipulate that the required information
> will be indicated in a policy qualifier, or the document to which a policy
> qualifier points. Such CPs can be considered parameterized definitions. The
> set of provisions should reference or define the required policy qualifier
> types and should specify any applicable default values.
> >
> > I think normally the policy qualifier points to a CPS, but it might be
> some other document.
> > But in any case if both CP & CPS say "No stipulation" in regards to
> something that Mozilla cares about like what validation methods are
> supported for TLS certificates, then it is very hard to evaluate that set
> of "disclosed business practices" to determine if the CA operates in accord
> with the BRs or Mozilla's policy.
> > I think there may be some sections of a CP/CPS that are less critical,
> but in terms of any section that is critical to the evaluation for
> inclusion in a particular trust store, I would expect one of the 2
> documents to clearly state the operational practices of the CA rather than
> just stating "No Stipulation" in both CP & CPS, unless the Policy Qualifier
> in issued certificates points to some other document that contains that
> information.
> >
> > Again - just my personal opinion.
> >
> >  wendy
> >
>
>
> ___
> 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: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

2018-10-09 Thread Kathleen Wilson via dev-security-policy
Oh, so rather than trying to define what "No Stipulation" means and when 
it can be used, we could take a different approach -- list the sections 
that cannot contain "No Stipulation" in the CPS.



On 10/9/18 12:31 PM, Brown, Wendy (10421) wrote:

Tim  -

I think that statement leaves out the next paragraph of RFC3647:
In a CP, it is possible to leave certain components, subcomponents, and/or 
elements unspecified, and to stipulate that the required information will be 
indicated in a policy qualifier, or the document to which a policy qualifier 
points. Such CPs can be considered parameterized definitions. The set of 
provisions should reference or define the required policy qualifier types and 
should specify any applicable default values.

I think normally the policy qualifier points to a CPS, but it might be some 
other document.
But in any case if both CP & CPS say "No stipulation" in regards to something that 
Mozilla cares about like what validation methods are supported for TLS certificates, then it is very 
hard to evaluate that set of "disclosed business practices" to determine if the CA operates 
in accord with the BRs or Mozilla's policy.
I think there may be some sections of a CP/CPS that are less critical, but in terms of any 
section that is critical to the evaluation for inclusion in a particular trust store, I would 
expect one of the 2 documents to clearly state the operational practices of the CA rather 
than just stating "No Stipulation" in both CP & CPS, unless the Policy 
Qualifier in issued certificates points to some other document that contains that information.

Again - just my personal opinion.

 wendy




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


RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

2018-10-09 Thread Brown, Wendy (10421) via dev-security-policy
Tim  -

I think that statement leaves out the next paragraph of RFC3647:
In a CP, it is possible to leave certain components, subcomponents, and/or 
elements unspecified, and to stipulate that the required information will be 
indicated in a policy qualifier, or the document to which a policy qualifier 
points. Such CPs can be considered parameterized definitions. The set of 
provisions should reference or define the required policy qualifier types and 
should specify any applicable default values.

I think normally the policy qualifier points to a CPS, but it might be some 
other document.
But in any case if both CP & CPS say "No stipulation" in regards to something 
that Mozilla cares about like what validation methods are supported for TLS 
certificates, then it is very hard to evaluate that set of "disclosed business 
practices" to determine if the CA operates in accord with the BRs or Mozilla's 
policy.
I think there may be some sections of a CP/CPS that are less critical, but in 
terms of any section that is critical to the evaluation for inclusion in a 
particular trust store, I would expect one of the 2 documents to clearly state 
the operational practices of the CA rather than just stating "No Stipulation" 
in both CP & CPS, unless the Policy Qualifier in issued certificates points to 
some other document that contains that information.

Again - just my personal opinion.

wendy



Date: Tue, 9 Oct 2018 19:02:54 +

From: Tim Hollebeek 
mailto:tim.holleb...@digicert.com>>

To: 
"dev-security-policy@lists.mozilla.org"


mailto:dev-security-policy@lists.mozilla.org>>

Subject: RE: What does "No Stipulation" mean, and when is it OK to use

it in CP/CPS?

Message-ID:


mailto:bn6pr14mb110664cd140c0a82f006afa483...@bn6pr14mb1106.namprd14.prod.outlook.com>>



Content-Type: text/plain; charset="us-ascii"



RFC 3647 disagrees:



"Rather, a particular CP or CPS may state "no stipulation" for a component,  
subcomponent, or element on which the particular CP or CPS imposes no  
requirements or makes no disclosure."



" It is recommended that each and every component and subcomponent be

   included in a CP or CPS, even if there is "no stipulation"; this will

   indicate to the reader that a conscious decision was made to include

   or exclude a provision concerning that topic.  This drafting style

   protects against inadvertent omission of a topic, while facilitating

   comparison of different certificate policies or CPSs, e.g., when

   making policy mapping decisions."



-Tim



> -Original Message-

> From: dev-security-policy

> mailto:dev-security-policy-boun...@lists.mozilla.org>>

> On Behalf Of Brown, Wendy (10421) via dev-security-policy

> Sent: Tuesday, October 9, 2018 2:55 PM

> To: 
> dev-security-policy@lists.mozilla.org

> Subject: RE: What does "No Stipulation" mean, and when is it OK to use

> it

in

> CP/CPS?

>

> Kathleen -

> My interpretation of a "No Stipulation" in a CP is that the Policy has

> "No

rules

> defined for this section"

> In these cases, I expect the CPS to state what is actually done in

> support

of

> that section and therefore "No Stipulation" is not appropriate in a CPS.

The

> CPS should instead state whether or not they implement anything in

response

> to that section or if they consider that section Not Applicable

> because

there

> are no stated requirements.

>

> It can mean slightly different things in different sections so for

> example

> 1.3.5 Other Participants - I would expect the CPS to list what other

> participants might be involved Where as

> 3.1.5 Uniqueness of Names - I would expect the CPS to state whether or

> not they enforce Uniqueness of names and if they do - how this is

> enforced In

a

> TLS CP/CPS that adheres to the BRs, I would expect the CPS to clearly

state

> which of the validation methods is supported and how, where the CP may

> leave this up to individual subordinate CAs by having No Stipulation

> at

the CP

> level.  For these sections I would expect the CPS to either state the

method is

> not supported or it is and how.  "Not applicable" would not be

appropriate.

>

> Thanks, (just my personal opinion)

>

> Wendy Brown

> Protiviti Government Services

> 703-299-4705 (office)703-965-2990 (cell)

>

> wendy.br...@protiviti.com

>

>

> -

>

> Date: Tue, 9 Oct 2018 09:48:26 -0700

> From: Kathleen Wilson mailto:kwil...@mozilla.com>>

> To: 
> mozilla-dev-security-pol...@lists.mozilla.org

> Subject: What does "No Stipulation" mean, and when is it OK to use it

> in CP/CPS?

> Message-ID: 
> mailto:n5sdneed28pgrihgnz2dnuu7-fpnn...@mozilla.org>>

> Content-Type: text/plain; charset=utf-8; format=flowed

>

> All,

>

> I would 

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-09 Thread Tim Hollebeek via dev-security-policy
RFC 3647 disagrees:

"Rather, a particular CP or CPS may state "no stipulation" for a component,
 subcomponent, or element on which the particular CP or CPS imposes no
 requirements or makes no disclosure."

" It is recommended that each and every component and subcomponent be
   included in a CP or CPS, even if there is "no stipulation"; this will
   indicate to the reader that a conscious decision was made to include
   or exclude a provision concerning that topic.  This drafting style
   protects against inadvertent omission of a topic, while facilitating
   comparison of different certificate policies or CPSs, e.g., when
   making policy mapping decisions."

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Brown, Wendy (10421) via dev-security-policy
> Sent: Tuesday, October 9, 2018 2:55 PM
> To: dev-security-policy@lists.mozilla.org
> Subject: RE: What does "No Stipulation" mean, and when is it OK to use it
in
> CP/CPS?
> 
> Kathleen -
> My interpretation of a "No Stipulation" in a CP is that the Policy has "No
rules
> defined for this section"
> In these cases, I expect the CPS to state what is actually done in support
of
> that section and therefore "No Stipulation" is not appropriate in a CPS.
The
> CPS should instead state whether or not they implement anything in
response
> to that section or if they consider that section Not Applicable because
there
> are no stated requirements.
> 
> It can mean slightly different things in different sections so for example
> 1.3.5 Other Participants - I would expect the CPS to list what other
> participants might be involved Where as
> 3.1.5 Uniqueness of Names - I would expect the CPS to state whether or not
> they enforce Uniqueness of names and if they do - how this is enforced In
a
> TLS CP/CPS that adheres to the BRs, I would expect the CPS to clearly
state
> which of the validation methods is supported and how, where the CP may
> leave this up to individual subordinate CAs by having No Stipulation at
the CP
> level.  For these sections I would expect the CPS to either state the
method is
> not supported or it is and how.  "Not applicable" would not be
appropriate.
> 
> Thanks, (just my personal opinion)
> 
> Wendy Brown
> Protiviti Government Services
> 703-299-4705 (office)703-965-2990 (cell)
> 
> wendy.br...@protiviti.com
> 
> 
> -
> 
> Date: Tue, 9 Oct 2018 09:48:26 -0700
> From: Kathleen Wilson 
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> All,
> 
> I would like to create some written rules about using "No Stipulation"
> in CP and CPS documents; e.g. what it means, and when it is OK to be used.
> 
> First, I will appreciate your thoughts about what the term "No
Stipulation"
> means. e.g. does it mean one or all of the following?
>   "No rules defined for this section"
>   "This section is not applicable"
>   "This section is not allowed"
>   "This section is not used"
> 
> Can "No Stipulation" mean different things based on the context of the
> section?
> For example
> "1.3.5 Other Participants
> No stipulation."
> Does that mean ?no other participants are allowed??
> 
> Here is what RFC 3647 says about the term:
> ""
> While many topics are identified, it is not necessary for a CP or a
> CPS to include a concrete statement for every such topic.  Rather, a
> particular CP or CPS may state "no stipulation" for a component,
> subcomponent, or element on which the particular CP or CPS imposes no
> requirements or makes no disclosure.  In this sense, the list of
> topics can be considered a checklist of topics for consideration by
> the CP or CPS writer.
> 
> It is recommended that each and every component and subcomponent be
> included in a CP or CPS, even if there is "no stipulation"; this will
> indicate to the reader that a conscious decision was made to include
> or exclude a provision concerning that topic.  This drafting style
> protects against inadvertent omission of a topic, while facilitating
> comparison of different certificate policies or CPSs, e.g., when
> making policy mapping decisions.
> ""
> 
> It seems a little ambiguous to me, so I would like to have a written
statement
> about what "No Stipulation" means within CP and CPS documents, especially
> in regards to SSL certificate issuance.
> 
> Here are two examples that I've seen recently.
> 
> == Example 1 ==
> In this situation, the CA has one CP that covers different types of roots,
so
> the CPS for the different roots has the details. There is no further
detailed
> public documentation beyond the CPS.
> 
> In the CA's CP:
> 3.1.2 Need for Names to be Meaningful
> No Stipulation
> 3.1.5 Uniqueness of Names
> No Stipulation
> 3.2.2.1 Identity
> No Stipulation
> 3.2.2.2 DBA/Tradename
> No Stipulation
> 

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-09 Thread Brown, Wendy (10421) via dev-security-policy
Kathleen -
My interpretation of a "No Stipulation" in a CP is that the Policy has "No 
rules defined for this section"
In these cases, I expect the CPS to state what is actually done in support of 
that section and therefore "No Stipulation" is not appropriate in a CPS.  The 
CPS should instead state whether or not they implement anything in response to 
that section or if they consider that section Not Applicable because there are 
no stated requirements.

It can mean slightly different things in different sections so for example
1.3.5 Other Participants - I would expect the CPS to list what other 
participants might be involved
Where as
3.1.5 Uniqueness of Names - I would expect the CPS to state whether or not they 
enforce Uniqueness of names and if they do - how this is enforced
In a TLS CP/CPS that adheres to the BRs, I would expect the CPS to clearly 
state which of the validation methods is supported and how, where the CP may 
leave this up to individual subordinate CAs by having No Stipulation at the CP 
level.  For these sections I would expect the CPS to either state the method is 
not supported or it is and how.  "Not applicable" would not be appropriate.

Thanks, (just my personal opinion)

Wendy Brown
Protiviti Government Services
703-299-4705 (office)703-965-2990 (cell)

wendy.br...@protiviti.com


-

Date: Tue, 9 Oct 2018 09:48:26 -0700
From: Kathleen Wilson 
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: What does "No Stipulation" mean, and when is it OK to use it
in CP/CPS?
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

All,

I would like to create some written rules about using "No Stipulation"
in CP and CPS documents; e.g. what it means, and when it is OK to be used.

First, I will appreciate your thoughts about what the term "No Stipulation" 
means. e.g. does it mean one or all of the following?
  "No rules defined for this section"
  "This section is not applicable"
  "This section is not allowed"
  "This section is not used"

Can "No Stipulation" mean different things based on the context of the section?
For example
"1.3.5 Other Participants
No stipulation."
Does that mean ?no other participants are allowed??

Here is what RFC 3647 says about the term:
""
While many topics are identified, it is not necessary for a CP or a
CPS to include a concrete statement for every such topic.  Rather, a
particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure.  In this sense, the list of
topics can be considered a checklist of topics for consideration by
the CP or CPS writer.

It is recommended that each and every component and subcomponent be
included in a CP or CPS, even if there is "no stipulation"; this will
indicate to the reader that a conscious decision was made to include
or exclude a provision concerning that topic.  This drafting style
protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions.
""

It seems a little ambiguous to me, so I would like to have a written statement 
about what "No Stipulation" means within CP and CPS documents, especially in 
regards to SSL certificate issuance.

Here are two examples that I've seen recently.

== Example 1 ==
In this situation, the CA has one CP that covers different types of roots, so 
the CPS for the different roots has the details. There is no further detailed 
public documentation beyond the CPS.

In the CA's CP:
3.1.2 Need for Names to be Meaningful
No Stipulation
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.1 Identity
No Stipulation
3.2.2.2 DBA/Tradename
No Stipulation
3.2.2.3 Verification of Country
No Stipulation
3.2.2.4 Validation of Domain Authorization or Control No Stipulation
3.2.2.4.1 Validating the Applicant as a Domain Contact No Stipulation
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact No Stipulation
3.2.2.4.3 Phone Contact with Domain Contact No Stipulation
3.2.2.4.4 Constructed Email to Domain Contact No Stipulation
3.2.2.4.5 Domain Authorization Document
No Stipulation
3.2.2.4.6 Agreed-Upon Change to Website
No Stipulation
3.2.2.4.7 DNS Change
No Stipulation
3.2.2.4.8 IP Address
No Stipulation
3.2.2.4.9 Test Certificate
No Stipulation
3.2.2.4.10 TLS Using a Random Number
No Stipulation
3.2.2.4.11 Any Other Method
This method has been retired and MUST NOT be used.
3.2.2.4.12 Validating Applicant as a Domain Contact No Stipulation
3.2.2.5 Authentication for an IP Address No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
3.2.2.7 Data Source Accuracy
No Stipulation
3.2.2.8 CAA Records
No Stipulation
3.2.3 Authentication of Individual Identity No Stipulation
3.2.4 Non-Verified Subscriber Information No Stipulation
4.7.4 Notification of New Certificate Issuance to 

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-09 Thread (RS) Tyler Schroder via dev-security-policy
The legal definition that I came acrosss is " In United States 
law, a stipulation is a formal 
legal acknowledgment and agreement made between opposing parties before a 
pending hearing or 
trial. For example, both parties 
might stipulate to certain facts and so not have to argue them in court. After 
the stipulation is entered into, it is presented to the judge." [1]


On 10/9/2018 12:48 PM, Kathleen Wilson via dev-security-policy wrote:

CAUTION: This message was sent from outside the company.


All,

I would like to create some written rules about using "No Stipulation"
in CP and CPS documents; e.g. what it means, and when it is OK to be used.

First, I will appreciate your thoughts about what the term "No
Stipulation" means. e.g. does it mean one or all of the following?
 "No rules defined for this section"
 "This section is not applicable"
 "This section is not allowed"
 "This section is not used"

Can "No Stipulation" mean different things based on the context of the
section?
For example
"1.3.5 Other Participants
No stipulation."
Does that mean “no other participants are allowed”?

Here is what RFC 3647 says about the term:
""
While many topics are identified, it is not necessary for a CP or a
   CPS to include a concrete statement for every such topic.  Rather, a
   particular CP or CPS may state "no stipulation" for a component,
   subcomponent, or element on which the particular CP or CPS imposes no
   requirements or makes no disclosure.  In this sense, the list of
   topics can be considered a checklist of topics for consideration by
   the CP or CPS writer.

   It is recommended that each and every component and subcomponent be
   included in a CP or CPS, even if there is "no stipulation"; this will
   indicate to the reader that a conscious decision was made to include
   or exclude a provision concerning that topic.  This drafting style
   protects against inadvertent omission of a topic, while facilitating
   comparison of different certificate policies or CPSs, e.g., when
   making policy mapping decisions.
""

It seems a little ambiguous to me, so I would like to have a written
statement about what "No Stipulation" means within CP and CPS documents,
especially in regards to SSL certificate issuance.

Here are two examples that I've seen recently.

== Example 1 ==
In this situation, the CA has one CP that covers different types of
roots, so the CPS for the different roots has the details. There is no
further detailed public documentation beyond the CPS.

In the CA's CP:
3.1.2 Need for Names to be Meaningful
No Stipulation
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.1 Identity
No Stipulation
3.2.2.2 DBA/Tradename
No Stipulation
3.2.2.3 Verification of Country
No Stipulation
3.2.2.4 Validation of Domain Authorization or Control
No Stipulation
3.2.2.4.1 Validating the Applicant as a Domain Contact
No Stipulation
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
No Stipulation
3.2.2.4.3 Phone Contact with Domain Contact
No Stipulation
3.2.2.4.4 Constructed Email to Domain Contact
No Stipulation
3.2.2.4.5 Domain Authorization Document
No Stipulation
3.2.2.4.6 Agreed-Upon Change to Website
No Stipulation
3.2.2.4.7 DNS Change
No Stipulation
3.2.2.4.8 IP Address
No Stipulation
3.2.2.4.9 Test Certificate
No Stipulation
3.2.2.4.10 TLS Using a Random Number
No Stipulation
3.2.2.4.11 Any Other Method
This method has been retired and MUST NOT be used.
3.2.2.4.12 Validating Applicant as a Domain Contact
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
3.2.2.7 Data Source Accuracy
No Stipulation
3.2.2.8 CAA Records
No Stipulation
3.2.3 Authentication of Individual Identity
No Stipulation
3.2.4 Non-Verified Subscriber Information
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No stipulation
4.9.7 CRL Issuance Frequency
No Stipulation.
4.9.10 On-Line Revocation Checking Requirements
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.1.5 Key Sizes
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation
6.3.2 Certificate Operational Periods and Key Pair Usage Periods
No Stipulation
6.7 NETWORK SECURITY CONTROLS
No stipulation

The relevant CPS has the following sections with No Stipulation:
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival

What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-09 Thread Kathleen Wilson via dev-security-policy

All,

I would like to create some written rules about using "No Stipulation" 
in CP and CPS documents; e.g. what it means, and when it is OK to be used.


First, I will appreciate your thoughts about what the term "No 
Stipulation" means. e.g. does it mean one or all of the following?

 "No rules defined for this section"
 "This section is not applicable"
 "This section is not allowed"
 "This section is not used"

Can "No Stipulation" mean different things based on the context of the 
section?

For example
"1.3.5 Other Participants
No stipulation."
Does that mean “no other participants are allowed”?

Here is what RFC 3647 says about the term:
""
While many topics are identified, it is not necessary for a CP or a
   CPS to include a concrete statement for every such topic.  Rather, a
   particular CP or CPS may state "no stipulation" for a component,
   subcomponent, or element on which the particular CP or CPS imposes no
   requirements or makes no disclosure.  In this sense, the list of
   topics can be considered a checklist of topics for consideration by
   the CP or CPS writer.

   It is recommended that each and every component and subcomponent be
   included in a CP or CPS, even if there is "no stipulation"; this will
   indicate to the reader that a conscious decision was made to include
   or exclude a provision concerning that topic.  This drafting style
   protects against inadvertent omission of a topic, while facilitating
   comparison of different certificate policies or CPSs, e.g., when
   making policy mapping decisions.
""

It seems a little ambiguous to me, so I would like to have a written 
statement about what "No Stipulation" means within CP and CPS documents, 
especially in regards to SSL certificate issuance.


Here are two examples that I've seen recently.

== Example 1 ==
In this situation, the CA has one CP that covers different types of 
roots, so the CPS for the different roots has the details. There is no 
further detailed public documentation beyond the CPS.


In the CA's CP:
3.1.2 Need for Names to be Meaningful
No Stipulation
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.1 Identity
No Stipulation
3.2.2.2 DBA/Tradename
No Stipulation
3.2.2.3 Verification of Country
No Stipulation
3.2.2.4 Validation of Domain Authorization or Control
No Stipulation
3.2.2.4.1 Validating the Applicant as a Domain Contact
No Stipulation
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
No Stipulation
3.2.2.4.3 Phone Contact with Domain Contact
No Stipulation
3.2.2.4.4 Constructed Email to Domain Contact
No Stipulation
3.2.2.4.5 Domain Authorization Document
No Stipulation
3.2.2.4.6 Agreed-Upon Change to Website
No Stipulation
3.2.2.4.7 DNS Change
No Stipulation
3.2.2.4.8 IP Address
No Stipulation
3.2.2.4.9 Test Certificate
No Stipulation
3.2.2.4.10 TLS Using a Random Number
No Stipulation
3.2.2.4.11 Any Other Method
This method has been retired and MUST NOT be used.
3.2.2.4.12 Validating Applicant as a Domain Contact
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
3.2.2.7 Data Source Accuracy
No Stipulation
3.2.2.8 CAA Records
No Stipulation
3.2.3 Authentication of Individual Identity
No Stipulation
3.2.4 Non-Verified Subscriber Information
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No stipulation
4.9.7 CRL Issuance Frequency
No Stipulation.
4.9.10 On-Line Revocation Checking Requirements
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.1.5 Key Sizes
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation
6.3.2 Certificate Operational Periods and Key Pair Usage Periods
No Stipulation
6.7 NETWORK SECURITY CONTROLS
No stipulation

The relevant CPS has the following sections with No Stipulation:
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation

In this example you can see that the CA clarifies in the CPS which 
domain validation methods can be used.


I'm not sure how to interpret the sections listed above that have "No 
Stipulation" in both the CP and the CPS.


For instance, when I see "3.2.2.5 Authentication for an IP Address" with 
"No Stipulation" in the CPS, it is not clear to me if the CA does not 
allow for IP Addresses to be included in SSL certs, or if the CA just 
allows any form of verification of IP Addresses.




== 

Odp.: 46 Certificates issued with BR violations (KIR)

2018-10-09 Thread Grabowski Piotr via dev-security-policy
Hello Wayne,

Please find our comments below:


So far the process for modifying policy templates was controlled by only one 
person at the moment. Although these persons
have an extensive experience in PKI and preparing certificate templates and in 
common daily duties they work with serveral CA's and with hundreds of templates 
and it was the first (and we hope the last) time that something was 
misconfigured . This incident showed us that this process should be definitely 
changed and that's why practicing due care we are updating remediation steps or 
plan for:

1. Reviewed all certificate policy templates for ensuring that all of them are 
BR comliant.  /done
2. All the certificates owners were contacted and agreed on issuance new BR 
compliant certificates in time convenient for them, preferably not later than 
by  the end of this year and revocation current ones. /done
3. Added procedural step for periodic certificate policy templates validation. 
/done

4. Implement dual CAO control for modifying policy template which requires the 
presence of 2 CAO's (Certification Authority Operators)  /done
5. CAO audit logs will be daily scanned by system Auditor for policy change 
events and comapared if they match events from point 4) /done
6. Implement pre-issuance linting - we have sent request, urgent need to our 
PKI software vendor about delivery this functionality.
If we know the timeframe we will update this report.

Do you think it is a sufficient response to incident?

Best Reagrds
Piotr Grabowski

Od: Wayne Thayer 
Wysłane: poniedziałek, 8 października 2018 19:13:46
Do: Grabowski Piotr
DW: mozilla-dev-security-policy
Temat: Re: 46 Certificates issued with BR violations (KIR)

Thank you for the incident report. I have posted it to the bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495497

On Mon, Oct 8, 2018 at 8:25 AM piotr.grabowski--- via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Here's the incident report:

1.How your CA first became aware of the problem (e.g. via a problem report 
submitted to your Problem Reporting Mechanism, via a

discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.

Email from Wayne Thayer Oct 1, 2018

2.A timeline of the actions your CA took in response.

A. Oct 2, 2018 - Investigation began.
B. Oct 4, 2018 - Found impacted certificate policy templates.
C  Oct 4, 2018 - All the certificates owners were contacted and agreed on 
issuance new BR compliant certificates in time convenient for them, 
 preferably not later than by the end of this year and revocation current 
ones.
D. Oct 8, 2018 - Fixed impacted certificate policy templates.
E. Oct 8, 2018 - This disclosure.

Ongoing:
F. Replacement of impacted certificates
G. Training of periodic certificate policy templates validation.

3.Confirmation that your CA has stopped issuing TLS/SSL certificates with 
the problem.

Confirmed.

4.A summary of the problematic certificates. For each problem: number of 
certs, and the date the first and last certs with that problem

were issued.

There are 46 certificates.  The certificates were issued between Feb 20, 2017 
and Sep 25, 2018.

5.The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is

logged to CT and then list the fingerprints or crt.sh IDs, either in the report 
or as an attached spreadsheet, with one list per distinct
problem.

Added as attachment
https://crt.sh/?caid=15985=cablint,zlint,x509lint=2017-01-01

6.Explanation about how and why the mistakes were made or bugs introduced, 
and how they avoided detection until now.

The the incident concerns 46 certificates in the vast majority issued on KIR 
S.A. internal system purposes.
The root cause of this issue was human error in certificate policy templates.

"Human error" is not a sufficient response to this questions. Please describe 
the process in place for modifying policy templates and how it failed to catch 
this problem.

Remediation items:

1. Reviewed all certificate policy templates for ensuring that all of them are 
BR comliant.
2. All the certificates owners were contacted and agreed on issuance new BR 
compliant certificates in time convenient for them, preferably not later than 
by the end of this year and revocation current ones.
3. Added procedural step for periodic certificate policy templates validation.

None of these remediation items will prevent future problems of this nature. 
How will you improve your processes to prevent future misissuance?

I assume that KIR S.A. has not implemented pre-issuance linting. Why not? Is 
there a plan to implement pre-issuance linting? When?

We have by the way question about error: ERROR: The 'Organization Name' field 
of the subject MUST be less than 64 characters.
According to https://www.ietf.org/rfc/rfc5280.txt and the note from this RFC 

Re: Yet more undisclosed intermediates [Telia]

2018-10-09 Thread Jakob Bohm via dev-security-policy

[ Please reply to list, Mozilla NNTP<->mail gateway seems to insert
wrong Reply-To ]

Telia is a notable case as this seems to be a brand new Intermediary
created but not disclosed 1 month ago.

On 09/10/2018 12:43, Rob Stradling wrote:

"ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs
of the Mozilla Root Store Policy requirement [2] that
non-technically-constrained intermediate CA certificates...
"MUST be publicly disclosed in the CCADB by the CA that has their
 certificate included in Mozilla's root program. The CA with a
 certificate included in Mozilla's root program MUST disclose this
 information within a week of certificate creation, and before any
 such subordinate CA is allowed to issue certificates."

In their responses to "ACTION 6" [3], most CAs indicated that...
"We are aware of the requirements for intermediate certificate
 disclosure and have processes in place to ensure that these
 requirements are met"

There are currently 20 undisclosed non-technically-constrained
intermediates, belonging to 6 Root Owners, on "Rob's naughty list" [4]
(snapshot at [5]).  All 20 were undisclosed and listed (on [4]) on the
day the responses to [1] were due (September 30th), which means that
they have not been disclosed "within a week of certificate creation".

So, ISTM that the "processes in place to ensure that these requirements
are met" are insufficient/broken for at least the following Root Owners:
- Certicámara
- DigiCert
- DocuSign (OpenTrust/Keynectis)
- SECOM Trust Systems CO., LTD.
- SwissSign AG
- Telia Company (formerly TeliaSonera)

Wayne, Kathleen:
Given the number of times that all the CAs in Mozilla's Root Program
have been reminded about Mozilla's requirements for disclosing
intermediate certs, I wouldn't blame you if you decided to add these 20
intermediate certs [5] to OneCRL immediately!


[1]
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3rMGLL

[2]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited

[3]
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3rMGLL=Q00078,Q00079

[4] https://crt.sh/mozilla-disclosures#undisclosed

[5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed




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: Yet more undisclosed intermediates [SwissSign]

2018-10-09 Thread Jakob Bohm via dev-security-policy

[ Please reply to list, Mozilla NNTP<->mail gateway seems to insert
wrong Reply-To ]

It appears from the data that SwissSign has reacted to the requirement
by starting to log some of their existing intermediaries in CT, instead
of in CCADB.  At least at a cursory glance.

On 09/10/2018 12:43, Rob Stradling wrote:

"ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs
of the Mozilla Root Store Policy requirement [2] that
non-technically-constrained intermediate CA certificates...
"MUST be publicly disclosed in the CCADB by the CA that has their
 certificate included in Mozilla's root program. The CA with a
 certificate included in Mozilla's root program MUST disclose this
 information within a week of certificate creation, and before any
 such subordinate CA is allowed to issue certificates."

In their responses to "ACTION 6" [3], most CAs indicated that...
"We are aware of the requirements for intermediate certificate
 disclosure and have processes in place to ensure that these
 requirements are met"

There are currently 20 undisclosed non-technically-constrained
intermediates, belonging to 6 Root Owners, on "Rob's naughty list" [4]
(snapshot at [5]).  All 20 were undisclosed and listed (on [4]) on the
day the responses to [1] were due (September 30th), which means that
they have not been disclosed "within a week of certificate creation".

So, ISTM that the "processes in place to ensure that these requirements
are met" are insufficient/broken for at least the following Root Owners:
- Certicámara
- DigiCert
- DocuSign (OpenTrust/Keynectis)
- SECOM Trust Systems CO., LTD.
- SwissSign AG
- Telia Company (formerly TeliaSonera)

Wayne, Kathleen:
Given the number of times that all the CAs in Mozilla's Root Program
have been reminded about Mozilla's requirements for disclosing
intermediate certs, I wouldn't blame you if you decided to add these 20
intermediate certs [5] to OneCRL immediately!


[1]
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3rMGLL

[2]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited

[3]
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3rMGLL=Q00078,Q00079

[4] https://crt.sh/mozilla-disclosures#undisclosed

[5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed




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


Yet more undisclosed intermediates

2018-10-09 Thread Rob Stradling via dev-security-policy
"ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs 
of the Mozilla Root Store Policy requirement [2] that 
non-technically-constrained intermediate CA certificates...
   "MUST be publicly disclosed in the CCADB by the CA that has their
certificate included in Mozilla's root program. The CA with a
certificate included in Mozilla's root program MUST disclose this
information within a week of certificate creation, and before any
such subordinate CA is allowed to issue certificates."

In their responses to "ACTION 6" [3], most CAs indicated that...
   "We are aware of the requirements for intermediate certificate
disclosure and have processes in place to ensure that these
requirements are met"

There are currently 20 undisclosed non-technically-constrained 
intermediates, belonging to 6 Root Owners, on "Rob's naughty list" [4] 
(snapshot at [5]).  All 20 were undisclosed and listed (on [4]) on the 
day the responses to [1] were due (September 30th), which means that 
they have not been disclosed "within a week of certificate creation".

So, ISTM that the "processes in place to ensure that these requirements 
are met" are insufficient/broken for at least the following Root Owners:
   - Certicámara
   - DigiCert
   - DocuSign (OpenTrust/Keynectis)
   - SECOM Trust Systems CO., LTD.
   - SwissSign AG
   - Telia Company (formerly TeliaSonera)

Wayne, Kathleen:
Given the number of times that all the CAs in Mozilla's Root Program 
have been reminded about Mozilla's requirements for disclosing 
intermediate certs, I wouldn't blame you if you decided to add these 20 
intermediate certs [5] to OneCRL immediately!


[1] 
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3rMGLL

[2] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited

[3] 
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3rMGLL=Q00078,Q00079

[4] https://crt.sh/mozilla-disclosures#undisclosed

[5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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