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

[Peter Bowen via dev-security-policy]

On Fri, Jun 2, 2017 at 8:12 AM, Ryan Sleevi wrote:
> On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm wrote:
>
>> On 02/06/2017 15:54, Ryan Sleevi wrote:
>> > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote:
>> >
>> >> Yes, my concern is that this could make SIGNED{ToBeSigned} considered
>> >> misissuance if ToBeSigned is not a TBSCertificate.  For example, if I
>> >> could sign an ASN.1 sequence which had the following syntax:
>> >>
>> >> TBSNotCertificate ::= {
>> >> notACertificateUTF8String,
>> >> COMPONENTS OF TBSCertificate
>> >> }
>> >>
>> >> Someone could argue that this is mis-issuance because the resulting
>> >> "certificate" is clearly corrupt, as it fails to start with an
>> >> INTEGER.  On the other hand, I think that this is clearly not
>> >> mis-issuance of a certificate, as there is no sane implementation that
>> >> would accept this as a certificate.
>> >>
>> >
>> > Would it be a misissuance of a certificate? Hard to argue, I think.
>> >
>> > Would it be a misuse of key? I would argue yes, unless the
>> > TBSNotCertificate is specified/accepted for use in the CA side (e.g. IETF
>> > WD, at the least).
>> >
>> >
>> > The general principle I was trying to capture was one of "Only sign these
>> > defined structures, and only do so in a manner conforming to their
>> > appropriate encoding, and only do so after validating all the necessary
>> > information. Anything else is 'misissuance' - of a certificate, a CRL, an
>> > OCSP response, or a Signed-Thingy"
>> >
>>
>> Thing is, that there are still serious work involving the definition of
>> new CA-signed things, such as the recent (2017) paper on a super-
>> compressed CRL-equivalent format (available as a Firefox plugin).
>
>
> This does ny rely on CA signatures - but also perfectly demonstrates the
> point - that these things should be getting widely reviewed before
> implementing.
>>
>> Banning those by policy would be as bad as banning the first OCSP
>> responder because it was not yet on the old list {Certificate, CRL}.
>
>
> This argument presumes technical competence of CAs, for which collectively
> there is no demonstrable evidence.
>
> Functionally, this is identical to banning the "any other method" for
> domain validation. Yes, it allowed flexibility - but at the extreme cost to
> security.
>
> If there are new and compelling thing to sign, the community can review and
> the policy be updated. I cannot understand the argument against this basic
> security sanity check.
>
>
>>
>> Hence my suggested phrasing of "Anything that resembles a certificate"
>> (my actual wording a few posts up was more precise of cause).
>
>
> Yes, and I think that wording is insufficient and dangerous, despite your
> understandable goals, for the reasons I outlined.
>
> There is little objective technical or security reason to distinguish the
> thing that is signed - it should be a closed set (whitelists, not
> blacklists), just like algorithms, keysizes, or validation methods - due to
> the significant risk to security and stability.

Back in November 2016, I suggested that we try to create stricter
rules around CAs:
https://cabforum.org/pipermail/public/2016-November/008966.html and
https://groups.google.com/d/msg/mozilla.dev.security.policy/UqjD1Rff4pg/8sYO2uzNBwAJ.
It generated some discussion but I never pushed things forward.  Maybe
the following portion should be part of Mozilla policy?

Private Keys which are CA private keys must only be used to generate signatures
that meet the following requirements:

1. The signature must be over a SHA-256, SHA-384, or SHA-512 hash
2. The data being signed must be one of the following:
  * CA Certificate (a signed TBSCertificate, as defined in [RFC
5280](https://tools.ietf.org/html/rfc5280), with a
id-ce-basicConstraints extension with the cA component set to true)
  * End-entity Certificate (a signed TBSCertificate, as defined in
[RFC 5280](https://tools.ietf.org/html/rfc5280), that is not a CA
Certificate)
  * Certificate Revocation Lists (a signed TBSCertList as defined in
[RFC 5280](https://tools.ietf.org/html/rfc5280))
  * OCSP response (a signed ResponseData as defined in [RFC
6960](https://tools.ietf.org/html/rfc6960))
  * Precertificate (as defined in draft-ietf-trans-rfc6962-bis)
3. Data that does not meet the above requirements must not be signed

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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[David E. Ross via dev-security-policy]

On 6/2/2017 3:28 AM, Gervase Markham wrote:
> The scope of the BRs is ambiguous, and almost certainly smaller than the
> scope of the Mozilla policy. It might be useful to explicitly draw
> attention to that fact, for the avoidance of doubt.
> 
> Proposal: add a bullet to section 2.3, where we define BR exceptions:
> 
> "Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (section 1.1) overrides that. Mozilla expects
> CA operations relating to issuance of all SSL certificates in the scope
> of this policy to conform to the Baseline Requirements."
> 
> This is: https://github.com/mozilla/pkipolicy/issues/72
> 
> ---
> 
> This is a proposed update to Mozilla's root store policy for version
> 2.5. Please keep discussion in this group rather than on Github. Silence
> is consent.
> 
> Policy 2.4.1 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
> Update process:
> https://wiki.mozilla.org/CA:CertPolicyUpdates
> 

Consider:

While the Mozilla policy requires compliance with the Baseline
Requirements, this policy has a broader scope by levying additional
requirements on certification authorities.

-- 
David E. Ross


Consider:
*  Most state mandate that drivers have liability insurance.
*  Employers are mandated to have worker's compensation insurance.
*  If you live in a flood zone, flood insurance is mandatory.
*  If your home has a mortgage, fire insurance is mandatory.

Why then is mandatory health insurance so bad??
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Kurt Roeckx via dev-security-policy]

On Fri, Jun 02, 2017 at 04:50:44PM +0100, Gervase Markham wrote:
> On 02/06/17 12:24, Kurt Roeckx wrote:
> > Should that be "all certificates" instead of "all SSL certificates"?
> 
> No; the Baseline Requirements apply only to SSL certificates.

Then I don't understand what you're trying to do. If the BR
already apply to all SSL certificates, why would Mozilla need to
override this and say it applies to all SSL certificates?

The BR are at least confusing to what they claim to be about. The
title of the document says "for the issuance and management of
pubicly-trusted certificates". In the "notice to readers" they say
it's about server authentication, and seem to imply it doesn't
cover "web services", code signing, smime, ...

Maybe you want to say it also applies to client authentication?

I also think it's wrong to say it just applies to SSL
certificates, it also applies to at least the intermediate
CAs.

I also see very little reason why the BRs couldn't be applied to
all certificates if the put some effort in making the BRs actual
baseline requirements. About the only thing in the BRs that don't
apply to all certificates are the SAN requirements and things
related to having control over the domain name. It shouldn't be
that hard to move those things to a separate document instead.


Kurt

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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Peter Bowen via dev-security-policy]

On Fri, Jun 2, 2017 at 8:50 AM, Gervase Markham via
dev-security-policy  wrote:
> On 02/06/17 12:24, Kurt Roeckx wrote:
>> Should that be "all certificates" instead of "all SSL certificates"?
>
> No; the Baseline Requirements apply only to SSL certificates.

Should Mozilla include a clear definition of "SSL certificates" in the
policy?  And should it be based on technical attributes rather than
intent of the issuer?

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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

On 02/06/17 12:24, Kurt Roeckx wrote:
> Should that be "all certificates" instead of "all SSL certificates"?

No; the Baseline Requirements apply only to SSL certificates.

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

RE: [EXT] Symantec response to Google proposal

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, June 02, 2017 10:54 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec response to Google proposal
> 
> https://www.symantec.com/connect/blogs/symantec-s-response-google-
> s-subca-proposal
> 
> Symantec have responded to the Google proposal (which Mozilla has
> endorsed as the basis for further discussion) with a set of inline
comments
> which raise some objections to what is proposed.
> 
> Google will, no doubt, be evaluating these requests for change and
deciding
> to accept, or not, each of them. But Mozilla can make our own independent
> decisions on these points if we choose. If Google and Mozilla accept a
> change, it is accepted. If Google accepts it but we decline to accept, we
can
> add it to our list of additional requirements for Symantec instead.
> 
> Therefore, I would appreciate the community's careful consideration of the
> reasonableness of Symantec's requests for change to the proposal.
> 
> Gerv

Thank you for posting this, Gerv.  We intended to post the following here.
 


Posting on behalf of Symantec.
 
Today, after thoroughly reviewing Google's proposal and weighing its merits
against feedback we've heard from the broader community, including our CA
customers, we shared our response with Google and the community, and also
posted our full response on our blog at
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-pr
oposal 

We anticipate that Google and the community will need some time to review
our feedback and share their reactions, and we welcome their continued input
as we work to reach an agreed-upon plan that can be implemented in a
reasonable timeframe and ensures minimal disruption for our customers. We
thank our customers and the community for their valuable contributions to
this important discussion, and we will continue working toward what we
believe is the best path forward for all stakeholders.


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

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

[Ryan Sleevi via dev-security-policy]

On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 02/06/2017 15:54, Ryan Sleevi wrote:
> > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen  wrote:
> >
> >> On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi  wrote:
> >> Yes, my concern is that this could make SIGNED{ToBeSigned} considered
> >> misissuance if ToBeSigned is not a TBSCertificate.  For example, if I
> >> could sign an ASN.1 sequence which had the following syntax:
> >>
> >> TBSNotCertificate ::= {
> >> notACertificateUTF8String,
> >> COMPONENTS OF TBSCertificate
> >> }
> >>
> >> Someone could argue that this is mis-issuance because the resulting
> >> "certificate" is clearly corrupt, as it fails to start with an
> >> INTEGER.  On the other hand, I think that this is clearly not
> >> mis-issuance of a certificate, as there is no sane implementation that
> >> would accept this as a certificate.
> >>
> >
> > Would it be a misissuance of a certificate? Hard to argue, I think.
> >
> > Would it be a misuse of key? I would argue yes, unless the
> > TBSNotCertificate is specified/accepted for use in the CA side (e.g. IETF
> > WD, at the least).
> >
> > As a practical matter, this largely only applies to the use of signatures
> > for which collisions are possible - since, of course, the
> TBSNotCertificate
> > might be constructed in such a way to collide with the TBSCertificate.
> > As a "assume a jackass genie is interpreting the policy" matter, what
> about
> > situations where a TBSNotCertificate has the same structure as
> > TBSCertificate? The fact that they are identical representations
> > on-the-wire could be argued as irrelevant, since they are non-identical
> > representations "in the spec". Unfortunately, this scenario has come up
> > once before already - in the context of RFC 6962 (and hence the
> > clarifications in the Baseline Requirements) - so it's not unreasonable a
> > scenario to expect.
> >
> > The general principle I was trying to capture was one of "Only sign these
> > defined structures, and only do so in a manner conforming to their
> > appropriate encoding, and only do so after validating all the necessary
> > information. Anything else is 'misissuance' - of a certificate, a CRL, an
> > OCSP response, or a Signed-Thingy"
> >
>
> Thing is, that there are still serious work involving the definition of
> new CA-signed things, such as the recent (2017) paper on a super-
> compressed CRL-equivalent format (available as a Firefox plugin).


This does ny rely on CA signatures - but also perfectly demonstrates the
point - that these things should be getting widely reviewed before
implementing.


>
> Banning those by policy would be as bad as banning the first OCSP
> responder because it was not yet on the old list {Certificate, CRL}.


This argument presumes technical competence of CAs, for which collectively
there is no demonstrable evidence.

Functionally, this is identical to banning the "any other method" for
domain validation. Yes, it allowed flexibility - but at the extreme cost to
security.

If there are new and compelling thing to sign, the community can review and
the policy be updated. I cannot understand the argument against this basic
security sanity check.


>
> Hence my suggested phrasing of "Anything that resembles a certificate"
> (my actual wording a few posts up was more precise of cause).


Yes, and I think that wording is insufficient and dangerous, despite your
understandable goals, for the reasons I outlined.


>
> Note that signing a wrong CRL or OCSP response is still bad, but not
> mis-issuance.


What would you call it? A malformed OCSP response, when signed, can be
indistinguishable from a certificate.

There is little objective technical or security reason to distinguish the
thing that is signed - it should be a closed set (whitelists, not
blacklists), just like algorithms, keysizes, or validation methods - due to
the significant risk to security and stability.

>
>
>
> 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
>
___
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"

[Jakob Bohm via dev-security-policy]

On 02/06/2017 15:54, Ryan Sleevi wrote:

On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen  wrote:


On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi  wrote:
Yes, my concern is that this could make SIGNED{ToBeSigned} considered
misissuance if ToBeSigned is not a TBSCertificate.  For example, if I
could sign an ASN.1 sequence which had the following syntax:

TBSNotCertificate ::= {
notACertificateUTF8String,
COMPONENTS OF TBSCertificate
}

Someone could argue that this is mis-issuance because the resulting
"certificate" is clearly corrupt, as it fails to start with an
INTEGER.  On the other hand, I think that this is clearly not
mis-issuance of a certificate, as there is no sane implementation that
would accept this as a certificate.



Would it be a misissuance of a certificate? Hard to argue, I think.

Would it be a misuse of key? I would argue yes, unless the
TBSNotCertificate is specified/accepted for use in the CA side (e.g. IETF
WD, at the least).

As a practical matter, this largely only applies to the use of signatures
for which collisions are possible - since, of course, the TBSNotCertificate
might be constructed in such a way to collide with the TBSCertificate.
As a "assume a jackass genie is interpreting the policy" matter, what about
situations where a TBSNotCertificate has the same structure as
TBSCertificate? The fact that they are identical representations
on-the-wire could be argued as irrelevant, since they are non-identical
representations "in the spec". Unfortunately, this scenario has come up
once before already - in the context of RFC 6962 (and hence the
clarifications in the Baseline Requirements) - so it's not unreasonable a
scenario to expect.

The general principle I was trying to capture was one of "Only sign these
defined structures, and only do so in a manner conforming to their
appropriate encoding, and only do so after validating all the necessary
information. Anything else is 'misissuance' - of a certificate, a CRL, an
OCSP response, or a Signed-Thingy"



Thing is, that there are still serious work involving the definition of
new CA-signed things, such as the recent (2017) paper on a super-
compressed CRL-equivalent format (available as a Firefox plugin).

Banning those by policy would be as bad as banning the first OCSP
responder because it was not yet on the old list {Certificate, CRL}.

Hence my suggested phrasing of "Anything that resembles a certificate"
(my actual wording a few posts up was more precise of cause).

Note that signing a wrong CRL or OCSP response is still bad, but not
mis-issuance.


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"

[Ryan Sleevi via dev-security-policy]

On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen  wrote:

> On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi  wrote:
> Yes, my concern is that this could make SIGNED{ToBeSigned} considered
> misissuance if ToBeSigned is not a TBSCertificate.  For example, if I
> could sign an ASN.1 sequence which had the following syntax:
>
> TBSNotCertificate ::= {
>notACertificateUTF8String,
>COMPONENTS OF TBSCertificate
> }
>
> Someone could argue that this is mis-issuance because the resulting
> "certificate" is clearly corrupt, as it fails to start with an
> INTEGER.  On the other hand, I think that this is clearly not
> mis-issuance of a certificate, as there is no sane implementation that
> would accept this as a certificate.
>

Would it be a misissuance of a certificate? Hard to argue, I think.

Would it be a misuse of key? I would argue yes, unless the
TBSNotCertificate is specified/accepted for use in the CA side (e.g. IETF
WD, at the least).

As a practical matter, this largely only applies to the use of signatures
for which collisions are possible - since, of course, the TBSNotCertificate
might be constructed in such a way to collide with the TBSCertificate.
As a "assume a jackass genie is interpreting the policy" matter, what about
situations where a TBSNotCertificate has the same structure as
TBSCertificate? The fact that they are identical representations
on-the-wire could be argued as irrelevant, since they are non-identical
representations "in the spec". Unfortunately, this scenario has come up
once before already - in the context of RFC 6962 (and hence the
clarifications in the Baseline Requirements) - so it's not unreasonable a
scenario to expect.

The general principle I was trying to capture was one of "Only sign these
defined structures, and only do so in a manner conforming to their
appropriate encoding, and only do so after validating all the necessary
information. Anything else is 'misissuance' - of a certificate, a CRL, an
OCSP response, or a Signed-Thingy"
___
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"

[Peter Bowen via dev-security-policy]

On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi  wrote:
>
>
> On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy
>  wrote:
>>
>> On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy
>> > So I would definitely encourage that improper application of the
>> > protocols
>> > and data formats constitutes misissuance, as they directly affect
>> > interoperability and indirectly affect security :)
>>
>> I think the policy needs to be carefully thought out here, as there is
>> no limitation to what can be signed with the key used to sign
>> certificates.   What is a malformed certificate to one person might be
>> a valid document to someone else.  Maybe you could disallow signing
>> things that are not valid ASN.1 DER?
>
>
> I suspect you're raising a concern since a CA can use a SIGNED{ToBeSigned}
> construct from RFC 6025[1] to express a signature over a structure defined
> by "ToBeSigned", and wanting to distinguish that, for example, a certificate
> is not a CRL, as they're distinguished from their ToBeSigned construct. I
> would argue here that any signatures produced / structures provided should
> have an appropriate protocol or data format definition to justify the
> application of that signature, and that it would be misissuance in the
> absence of that support. Logically, I'm suggesting it's misissuance to, for
> example, expose a prehash signing oracle using a CA key, or to sign
> arbitrary data if it's not encoded 'like' a certificate (without having an
> equivalent appropriate standard defining what the CA is signing)

Yes, my concern is that this could make SIGNED{ToBeSigned} considered
misissuance if ToBeSigned is not a TBSCertificate.  For example, if I
could sign an ASN.1 sequence which had the following syntax:

TBSNotCertificate ::= {
   notACertificateUTF8String,
   COMPONENTS OF TBSCertificate
}

Someone could argue that this is mis-issuance because the resulting
"certificate" is clearly corrupt, as it fails to start with an
INTEGER.  On the other hand, I think that this is clearly not
mis-issuance of a certificate, as there is no sane implementation that
would accept this as a certificate.

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

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Ryan Sleevi via dev-security-policy]

I liked your previous version better, if it had to be updated.

It would sound like you're suggesting "Enterprise RA" accounts should not
use multi-factor authentication, but given that they're part of the scope
of audited activities (that the CA must directly oversee), the use of
multi-factor authentication seems both entirely appropriate and necessary
to maintaining the integrity of such systems.

So my preference was
1) Originally worded
2) "performing RA or DTP functions"
...
3) This wording :P

On Fri, Jun 2, 2017 at 6:00 AM, Gervase Markham  wrote:

> On 01/06/17 13:59, Gervase Markham wrote:
> > Perhaps this leads to the solution? We say:
> >
> > "enforce multi-factor authentication for all accounts capable of causing
> > certificate issuance or performing RA or DTP functions as defined by the
> > Baseline Requirements"
>
> or "enforce multi-factor authentication for all accounts capable of
> either causing certificate issuance or performing validation functions,
> for certificates containing domains not owned or controlled by the
> account holder"
>
> 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"

[Ryan Sleevi via dev-security-policy]

On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy
> > So I would definitely encourage that improper application of the
> protocols
> > and data formats constitutes misissuance, as they directly affect
> > interoperability and indirectly affect security :)
>
> I think the policy needs to be carefully thought out here, as there is
> no limitation to what can be signed with the key used to sign
> certificates.   What is a malformed certificate to one person might be
> a valid document to someone else.  Maybe you could disallow signing
> things that are not valid ASN.1 DER?
>

I'm not really sure I see the slippery slope argument you mention.

On the most basic level, this is describing what Mozilla considers
misissuance - warranting at least some discussion and, if appropriate,
updates to policies. It naturally suggests that, in order to improve both
security and transparency, the policy should be maximally applicable, and
then allow situational constructs to override, rather than to try to
accommodate every unknown hypothetically good activity.

For example, I think we'd easily agree that improper DER encoding is
misissuance - that's an improper application of the data format. I think
we'd also hopefully agree that if, for example, a CA asserted a set of KUs
that were 'validated', but not conformant to RFC 5280 (e.g. 5280 says MUST
NOT and a CA does it anyways), then that's an improper application of the
data format/protocol.

I suspect you're raising a concern since a CA can use a SIGNED{ToBeSigned}
construct from RFC 6025[1] to express a signature over a structure defined
by "ToBeSigned", and wanting to distinguish that, for example, a
certificate is not a CRL, as they're distinguished from their ToBeSigned
construct. I would argue here that any signatures produced / structures
provided should have an appropriate protocol or data format definition to
justify the application of that signature, and that it would be misissuance
in the absence of that support. Logically, I'm suggesting it's misissuance
to, for example, expose a prehash signing oracle using a CA key, or to sign
arbitrary data if it's not encoded 'like' a certificate (without having an
equivalent appropriate standard defining what the CA is signing)

It seems far better for avoiding confusion to treat everything as wrong,
and then if it is indeed acceptable, to modify the policy at that time. I
don't think we can reasonably give "the benefit of the doubt" anymore.

[1] https://tools.ietf.org/html/rfc6025#section-2.3
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Kurt Roeckx via dev-security-policy]

On 2017-06-02 12:28, Gervase Markham wrote:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla expects
CA operations relating to issuance of all SSL certificates in the scope
of this policy to conform to the Baseline Requirements."


Should that be "all certificates" instead of "all SSL certificates"?


Kurt

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

Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

The scope of the BRs is ambiguous, and almost certainly smaller than the
scope of the Mozilla policy. It might be useful to explicitly draw
attention to that fact, for the avoidance of doubt.

Proposal: add a bullet to section 2.3, where we define BR exceptions:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla expects
CA operations relating to issuance of all SSL certificates in the scope
of this policy to conform to the Baseline Requirements."

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

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Gervase Markham via dev-security-policy]

On 01/06/17 13:59, Gervase Markham wrote:
> Perhaps this leads to the solution? We say:
> 
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing RA or DTP functions as defined by the
> Baseline Requirements"

or "enforce multi-factor authentication for all accounts capable of
either causing certificate issuance or performing validation functions,
for certificates containing domains not owned or controlled by the
account holder"

Gerv

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