Re: New undisclosed intermediates

2017-06-07 Thread Jonathan Rudenberg via dev-security-policy

> On Jun 7, 2017, at 21:56, Matthew Hardeman via dev-security-policy 
>  wrote:
> 
> On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote:
> 
>> Yet another batch of undisclosed intermediates has shown up in CT:
>> 
>> - 
>> https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
>> - 
>> https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
>> - 
>> https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca
>> - 
>> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
>> - 
>> https://crt.sh/?sha256=8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31
>> - 
>> https://crt.sh/?sha256=48db8801874e0e36b1b864603b31648b74e2322a8f9e4967a8f54bd1b8f594de
>> - 
>> https://crt.sh/?sha256=1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6
>> - 
>> https://crt.sh/?sha256=f1f072c64d69e573725533e83a601bb8b068f6699e59ba70eda2aecb28e06bfb
> 
> crt.sh seems to be unavailable / lagged at the moment, but before it went 
> down, I queried several of these.  MOST of those I queried seemed to be 
> self-issued / self-signed roots that I'm not sure are in the broader trust 
> stores directly.

Yes, they are self-signed, however they share a SPKI/Subject with one or more 
other certificates which make it possible to build paths to roots trusted by 
Mozilla.

Censys has a great visualization of this:

- 
https://censys.io/certificates/f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8/validation
- 
https://censys.io/certificates/29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619/validation
- 
https://censys.io/certificates/c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca/validation
- 
https://censys.io/certificates/c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca/validation
- 
https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation
- 
https://censys.io/certificates/8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31/validation
- 
https://censys.io/certificates/1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6/validation

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


Re: New undisclosed intermediates

2017-06-07 Thread Matthew Hardeman via dev-security-policy
On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote:

> Yet another batch of undisclosed intermediates has shown up in CT:
> 
> - 
> https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
> - 
> https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
> - 
> https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca
> - 
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> - 
> https://crt.sh/?sha256=8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31
> - 
> https://crt.sh/?sha256=48db8801874e0e36b1b864603b31648b74e2322a8f9e4967a8f54bd1b8f594de
> - 
> https://crt.sh/?sha256=1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6
> - 
> https://crt.sh/?sha256=f1f072c64d69e573725533e83a601bb8b068f6699e59ba70eda2aecb28e06bfb

crt.sh seems to be unavailable / lagged at the moment, but before it went down, 
I queried several of these.  MOST of those I queried seemed to be self-issued / 
self-signed roots that I'm not sure are in the broader trust stores directly.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: New undisclosed intermediates

2017-06-07 Thread Jonathan Rudenberg via dev-security-policy

> On Jun 5, 2017, at 09:29, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Happy Monday!
> 
> Another week, another set of intermediate certs that have shown up in CT
> without having been properly disclosed:
> https://crt.sh/mozilla-disclosures#undisclosed

Yet another batch of undisclosed intermediates has shown up in CT:

- 
https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
- 
https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
- 
https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca
- 
https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
- 
https://crt.sh/?sha256=8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31
- 
https://crt.sh/?sha256=48db8801874e0e36b1b864603b31648b74e2322a8f9e4967a8f54bd1b8f594de
- 
https://crt.sh/?sha256=1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6
- 
https://crt.sh/?sha256=f1f072c64d69e573725533e83a601bb8b068f6699e59ba70eda2aecb28e06bfb
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Mozilla requirements of Symantec

2017-06-07 Thread Jakob Bohm via dev-security-policy

Hi Gervase,

there seems to be a slight inconsistency between the terminology in the 
plan posted at


https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ

And the official letter quoted below.  I have added potential 
clarifications to fix this, please indicate, for the benefit of the 
community and Symantec if those clarifications are correct interpretations.


On 07/06/2017 20:51, Gervase Markham wrote:

Hi Steve,

I'm writing to you in your role as the Primary Point of Contact for
Symantec with regard to the Mozilla Root Program. I am writing with a
list of Mozilla-specific additions to the consensus remediation proposal
for Symantec, as documented by Google.

We note that you have raised a number of objections and queries with
regard to the consensus proposal. As you know, we are considering our
responses to those. We reserve the right to make additional requests of
Symantec in relation to any changes which might be made to that
proposal, or for other reasons.

However, we have formulated an initial list of Mozilla-specific addenda
to the consensus proposal and feel now is a good time to pass them on to
Symantec for your official consideration and comment. We would prefer
comments in mozilla.dev.security.policy (to which this notice has been
CCed), and in any event by close of business on Monday 12th June.

1) Mozilla would wish, after the 2017-08-08 date as documented in the
consensus proposal, to alter Firefox such that it trusts certificates
issued in the "new PKI" directly by embedding a set of certs or trust
anchors which are part of that PKI, and can therefore distrust any new
cert which is issued by the old PKI on a "notBefore" basis. We therefore
require that Symantec arrange their new PKI and provide us with
sufficient information in good time to be able to do that.



Potential clarification: By "New PKI", Mozilla apparently refers to the 
"Managed CAs", "Transition to a New Symantec PKI" and related parts of 
the plan, not to the "new roots" for the "modernized platform" / "new 
infrastructure".



2) Mozilla would wish, at some point in the future sooner than November
2020 (39 months after 2017-08-08, the date when Symantec need to be
doing new issuance from the new PKI), to be certain that we are fully
distrusting the old PKI. As things currently stand technically,
distrusting the old PKI would mean removing the roots, and so Symantec
would have to move their customers to the new PKI at a rate faster than
natural certificate expiry. Rather than arbitrarily set a date here, we
are willing to discuss what date might be reasonable with Symantec, but
would expect it to be some time in 2018.

As you know, Firefox currently does not act upon embedded CT
information, and so CT-based mechanisms are not a suitable basis for us
to determine trust upon. Were that to change, we may be able to consider
a continued trust of CT-logged certs, but would still want to dis-trust
non-CT-logged certs sooner than November 2020.

3) If any additional audit is performed by Symantec, including but not
limited to one that "that includes a description of the auditor’s tests
of controls and results", then the intended users of the audit report
must also include persons who assist in decisions related to the trusted
status of Certification Authorities within Mozilla products. For any
audit to unusually detailed criteria, it is permitted to place this
information behind a login (or require it to be so placed) as long as
Mozilla is allowed to give access to any member of our community that we
wish.



Potential clarification: Mozilla's #3 requirement applies to both the 
"new PKI" and the "new roots" for the "new infrastructure".



We look forward to hearing Symantec's response to these requirements.

With best wishes,

Gerv




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.5 Proposal: Add definition of "mis-issuance"

2017-06-07 Thread Jakob Bohm via dev-security-policy

On 07/06/2017 17:41, Ryan Sleevi wrote:

On Wed, Jun 7, 2017 at 11:25 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Note that I also had a second, related, point: The possibility that such
a new piece of infrastructure was, for other reasons, not endorsed by
Mozilla, but of great interest to one of the other root programs (not
all of which are browser vendors).

Conversely consider the possibility that some other root programs had a
similarly restrictive policy and refused to support the introduction of
CT PreCertificates.  This could have stopped a useful improvement that
Mozilla seems to like.

The Golden rule would then imply that Mozilla should not reserve to
itself a power it would not want other root programs to have.




So much rhetoric, so little substance...



As much as I love an application of the Golden Rule as the next person, I
think it again misunderstands the realities on the ground in the Web PKI,
and puts an ideal ahead of the practical security implications.
 > Root programs do sometimes disagree. For example, Microsoft reserves the
right to revoke certificates it disagrees with. That right means that other
browser programs cannot effectively use CRLs or OCSP for revocation, as to
do so is to recognize Microsoft's ability to (negatively) affect their
users. They have means of working out those disagreements.


Bad example, but illustrates that reasonable agreement is not always
obtainable.



You're positioning the hypothetical as if it's inflexible - but the reality
is, each root program exists to first and foremost best reflect the needs
of its userbase. For Microsoft, they've determined that's best accomplished
by giving themselves unilateral veto power over the CAs they trust. For
Mozilla, recognizing its global mission, it tries to operate openly and
best serving the ecosystem.



I'm saying that if someone not interested in some good protocol had veto
power over CAs using that protocol, then that someone could be
inflexible to the detriment of everyone else.  Hence the desire not to
establish a precedent for such veto power.

The goodness of Mozilla does not minimize that precedent, only increases
the danger it might be cited by less honorable root programs.


The scenario you remark as undesirable - the blocking of precertificates -
is, in fact, a desirable and appropriate outcome. As Nick has noted, these
efforts do not spring forth like Athena, fully grown and robust, but
iteratively develop through the community process - leaving ample time for
Mozilla to update and respond. This, too, has ample evidence of it
happening - see the discussions related to CAA, or the validation methods
employed by ACME.


So what would/should the CT project have done if some inflexible root 
program had vetoed its deployment?


And ample time to respond does not guarantee a fair response, especially
when considering the extension of such veto power to less flexible root
programs.



The idealized view of SDOs - that they are infallible organizations or
represent some neutral arbitration - is perhaps misguided. For example,
it's trivial to publish an I-D within the IETF as a draft, and it's not
unreasonable to have an absolutely terrible technology assigned an RFC (for
example, an informational submission documenting an existing, but insecure,
technology). As Nick mentions, the reality - and far more common occurrence
- is someone being clever and a half and doing it with good intentions, but
bad security. And those decisions - and that flexibility - create
significantly more risk for the overall ecosystem.


When talking about the IETF as an SDO, I am obviously talking about IETF
standards track working groups, not individual submission RFCs or BOF
talks at IETF meetings.



I suspect we will continue to disagree on this point, so I doubtful can
offer more meaningful arguments to sway you, and certainly would not appeal
to authority. I would simply note that the scenarios you raise as
hypotheticals do not and have not played out as you suggest, and if the
overall goal of this discussion is to ensure the security of Mozilla users,
then the contents, provenance, and correctness of what is signed plays an
inescapable part of that security, and the suggested flexibility is
inimical to that security.




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


Mozilla requirements of Symantec

2017-06-07 Thread Gervase Markham via dev-security-policy
Hi Steve,

I'm writing to you in your role as the Primary Point of Contact for
Symantec with regard to the Mozilla Root Program. I am writing with a
list of Mozilla-specific additions to the consensus remediation proposal
for Symantec, as documented by Google.

We note that you have raised a number of objections and queries with
regard to the consensus proposal. As you know, we are considering our
responses to those. We reserve the right to make additional requests of
Symantec in relation to any changes which might be made to that
proposal, or for other reasons.

However, we have formulated an initial list of Mozilla-specific addenda
to the consensus proposal and feel now is a good time to pass them on to
Symantec for your official consideration and comment. We would prefer
comments in mozilla.dev.security.policy (to which this notice has been
CCed), and in any event by close of business on Monday 12th June.

1) Mozilla would wish, after the 2017-08-08 date as documented in the
consensus proposal, to alter Firefox such that it trusts certificates
issued in the "new PKI" directly by embedding a set of certs or trust
anchors which are part of that PKI, and can therefore distrust any new
cert which is issued by the old PKI on a "notBefore" basis. We therefore
require that Symantec arrange their new PKI and provide us with
sufficient information in good time to be able to do that.

2) Mozilla would wish, at some point in the future sooner than November
2020 (39 months after 2017-08-08, the date when Symantec need to be
doing new issuance from the new PKI), to be certain that we are fully
distrusting the old PKI. As things currently stand technically,
distrusting the old PKI would mean removing the roots, and so Symantec
would have to move their customers to the new PKI at a rate faster than
natural certificate expiry. Rather than arbitrarily set a date here, we
are willing to discuss what date might be reasonable with Symantec, but
would expect it to be some time in 2018.

As you know, Firefox currently does not act upon embedded CT
information, and so CT-based mechanisms are not a suitable basis for us
to determine trust upon. Were that to change, we may be able to consider
a continued trust of CT-logged certs, but would still want to dis-trust
non-CT-logged certs sooner than November 2020.

3) If any additional audit is performed by Symantec, including but not
limited to one that "that includes a description of the auditor’s tests
of controls and results", then the intended users of the audit report
must also include persons who assist in decisions related to the trusted
status of Certification Authorities within Mozilla products. For any
audit to unusually detailed criteria, it is permitted to place this
information behind a login (or require it to be so placed) as long as
Mozilla is allowed to give access to any member of our community that we
wish.

We look forward to hearing Symantec's response to these requirements.

With best wishes,

Gerv

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


Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-07 Thread Ryan Sleevi via dev-security-policy
On Wed, Jun 7, 2017 at 11:25 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Note that I also had a second, related, point: The possibility that such
> a new piece of infrastructure was, for other reasons, not endorsed by
> Mozilla, but of great interest to one of the other root programs (not
> all of which are browser vendors).
>
> Conversely consider the possibility that some other root programs had a
> similarly restrictive policy and refused to support the introduction of
> CT PreCertificates.  This could have stopped a useful improvement that
> Mozilla seems to like.
>
> The Golden rule would then imply that Mozilla should not reserve to
> itself a power it would not want other root programs to have.


As much as I love an application of the Golden Rule as the next person, I
think it again misunderstands the realities on the ground in the Web PKI,
and puts an ideal ahead of the practical security implications.

Root programs do sometimes disagree. For example, Microsoft reserves the
right to revoke certificates it disagrees with. That right means that other
browser programs cannot effectively use CRLs or OCSP for revocation, as to
do so is to recognize Microsoft's ability to (negatively) affect their
users. They have means of working out those disagreements.

You're positioning the hypothetical as if it's inflexible - but the reality
is, each root program exists to first and foremost best reflect the needs
of its userbase. For Microsoft, they've determined that's best accomplished
by giving themselves unilateral veto power over the CAs they trust. For
Mozilla, recognizing its global mission, it tries to operate openly and
best serving the ecosystem.

The scenario you remark as undesirable - the blocking of precertificates -
is, in fact, a desirable and appropriate outcome. As Nick has noted, these
efforts do not spring forth like Athena, fully grown and robust, but
iteratively develop through the community process - leaving ample time for
Mozilla to update and respond. This, too, has ample evidence of it
happening - see the discussions related to CAA, or the validation methods
employed by ACME.

The idealized view of SDOs - that they are infallible organizations or
represent some neutral arbitration - is perhaps misguided. For example,
it's trivial to publish an I-D within the IETF as a draft, and it's not
unreasonable to have an absolutely terrible technology assigned an RFC (for
example, an informational submission documenting an existing, but insecure,
technology). As Nick mentions, the reality - and far more common occurrence
- is someone being clever and a half and doing it with good intentions, but
bad security. And those decisions - and that flexibility - create
significantly more risk for the overall ecosystem.

I suspect we will continue to disagree on this point, so I doubtful can
offer more meaningful arguments to sway you, and certainly would not appeal
to authority. I would simply note that the scenarios you raise as
hypotheticals do not and have not played out as you suggest, and if the
overall goal of this discussion is to ensure the security of Mozilla users,
then the contents, provenance, and correctness of what is signed plays an
inescapable part of that security, and the suggested flexibility is
inimical to that security.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-07 Thread Jakob Bohm via dev-security-policy

On 07/06/2017 16:43, Nick Lamb wrote:

On Tuesday, 6 June 2017 21:08:54 UTC+1, Ryan Sleevi  wrote:

Standards defining organization.


More usually a Standards _Development_ Organization. I wouldn't usually feel 
the need to offer this correction but in this context we care a good deal about 
the fact that SDOs are where the actual engineering is done, where the 
expertise about the particular niche being standardised exists.

Even in the IETF, which is unusual in having some pretty technical people 
making its top level decisions, the serious work is mostly done in specialist 
working groups, with their products percolating up afterwards. For most 
standards bodies the top level stuff is purely politics - at the ITU the 
members are (notionally) sovereign nations themselves, same for the UPU, at ISO 
they're entire national standards bodies, and so on - utterly unsuitable to the 
meat of standards development itself. Most expertise is instead present in 
smaller, specialised SDOs in these cases.

Anyway, to Jakob's point it is _extremely_ unlikely that a new piece of 
infrastructure will spring into existence fully formed and ready for use in 
anger in the Web PKI without enough time for Mozilla, and m.d.s.policy to 
evaluate it and if necessary update the relevant policy documents. Much more 
likely, in my opinion, is that something half-baked is tried by a CA, and later 
realised to have opened an unsuspected hole in security.

Nothing even prevents this policy being updated to permit, for example, trials 
of some particular promising new idea that needs testing at scale, although I 
think in most cases that won't be necessary. Consider the CRL signing idea, 
this can be tested perfectly well without using any trusted CA or subCA keys at 
all. A final production version would probably use trusted keys, but you don't 
need to start with them to see it work.



Note that I also had a second, related, point: The possibility that such
a new piece of infrastructure was, for other reasons, not endorsed by
Mozilla, but of great interest to one of the other root programs (not
all of which are browser vendors).

Conversely consider the possibility that some other root programs had a
similarly restrictive policy and refused to support the introduction of
CT PreCertificates.  This could have stopped a useful improvement that
Mozilla seems to like.

The Golden rule would then imply that Mozilla should not reserve to
itself a power it would not want other root programs to have.


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.5 Proposal: Add definition of "mis-issuance"

2017-06-07 Thread Jakob Bohm via dev-security-policy

On 07/06/2017 12:55, Rob Stradling wrote:

On 06/06/17 22:26, Jakob Bohm wrote:

On 06/06/2017 22:08, Ryan Sleevi wrote:



Signing data is heavily reliant on CA competency, and that's in
unfortunately short supply, as the economics of the CA market make it 
easy to fire all the engineers, while keeping the sales team, and

outsourcing the rest.


Ryan, thankfully at least some CAs have some engineers.  :-)


Which is why I am heavily focused on allowing new technology to be be
developed by competent non-CA staff (such as IETF),


Jakob, if I interpret that literally it seems you're objecting to CA 
staff contributing to IETF efforts.  If so, may I advise you to beware 
of TLS Feature (aka Must Staple), CAA, CT v1 (RFC6962) and especially CT 
v2 (6962-bis)?




No, I was just stating that if (as suggested by Mr. Sleevi) the Mozilla
root program does not trust CA engineers to design new to-be-signed data
formats, maybe Mozilla could at least trust designs that have been
positively peer reviewed in organizations such as the IETF, the NIST
computer security/crypto groups, etc. etc.

I was in no way suggesting that CA engineers do not participate in those
efforts, giving as an example their participation in early CT
deployments together with Google engineers.


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.5 Proposal: Add definition of "mis-issuance"

2017-06-07 Thread Nick Lamb via dev-security-policy
On Tuesday, 6 June 2017 21:08:54 UTC+1, Ryan Sleevi  wrote:
> Standards defining organization.

More usually a Standards _Development_ Organization. I wouldn't usually feel 
the need to offer this correction but in this context we care a good deal about 
the fact that SDOs are where the actual engineering is done, where the 
expertise about the particular niche being standardised exists.

Even in the IETF, which is unusual in having some pretty technical people 
making its top level decisions, the serious work is mostly done in specialist 
working groups, with their products percolating up afterwards. For most 
standards bodies the top level stuff is purely politics - at the ITU the 
members are (notionally) sovereign nations themselves, same for the UPU, at ISO 
they're entire national standards bodies, and so on - utterly unsuitable to the 
meat of standards development itself. Most expertise is instead present in 
smaller, specialised SDOs in these cases.

Anyway, to Jakob's point it is _extremely_ unlikely that a new piece of 
infrastructure will spring into existence fully formed and ready for use in 
anger in the Web PKI without enough time for Mozilla, and m.d.s.policy to 
evaluate it and if necessary update the relevant policy documents. Much more 
likely, in my opinion, is that something half-baked is tried by a CA, and later 
realised to have opened an unsuspected hole in security.

Nothing even prevents this policy being updated to permit, for example, trials 
of some particular promising new idea that needs testing at scale, although I 
think in most cases that won't be necessary. Consider the CRL signing idea, 
this can be tested perfectly well without using any trusted CA or subCA keys at 
all. A final production version would probably use trusted keys, but you don't 
need to start with them to see it work.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-07 Thread Rob Stradling via dev-security-policy

On 06/06/17 22:26, Jakob Bohm wrote:

On 06/06/2017 22:08, Ryan Sleevi wrote:



Signing data is heavily reliant on CA competency, and that's in
unfortunately short supply, as the economics of the CA market make it 
easy to fire all the engineers, while keeping the sales team, and

outsourcing the rest.


Ryan, thankfully at least some CAs have some engineers.  :-)


Which is why I am heavily focused on allowing new technology to be be
developed by competent non-CA staff (such as IETF),


Jakob, if I interpret that literally it seems you're objecting to CA 
staff contributing to IETF efforts.  If so, may I advise you to beware 
of TLS Feature (aka Must Staple), CAA, CT v1 (RFC6962) and especially CT 
v2 (6962-bis)?


;-)

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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