RE: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

2019-05-06 Thread Jeremy Rowley via dev-security-policy
I think it should be added by Mozilla. The CAB Forum is a long way from having 
an s/MIME policy in place (there's not even a working group yet). Having no 
policy for cert revocation related to s/MIME ignores that s/MIME are part of 
the Mozilla ecosystem and sequesters them from the rest of the policy.  Without 
a revocation policy, there's no requirement to revoke a certificate mis-issued 
that's non-TLS.

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Friday, May 3, 2019 12:44 PM
To: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME 
Certificates

Kathleen and Pedro,

Thank you for raising these legitimate concerns. I continue to believe that a 
literal reading of the current requirement is that it already does apply to 
S/MIME certificates, and the discussion I mentioned supports that 
interpretation.

I propose two new options to solve this problem:
* Remove S/MIME certificates from the scope of section 6 and wait for the CAB 
Forum to publish baseline requirements for S/MIME. I suspect that is a few 
years away given that the working group is still in the process of being 
chartered. However, this option is consistent with some people's interpretation 
of the existing requirements.
* Add a subsection on revocation specific to S/MIME certificates and populate 
it with a version of the BR requirements tailored to S/MIME. We'd probably need 
to include requirements for S/MIME Intermediates as well as leaf certificates.

A third option would be to specify the parts of the BR revocation requirements 
that don't apply to S/MIME certificates, but after reviewing section 4.9.1, I 
think this would be confusing, at best.

I would appreciate everyone's input on the best way to address this issue.

- Wayne


On Fri, May 3, 2019 at 5:12 AM Pedro Fuentes via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Hello,
> my main concern about applying this would be that this would lead to 
> forbid the option to suspend a personal certificate.
>
> On a side note about suspension... I was not active in the forums when 
> this was discussed and adopted and I'm sure there was a clear benefit 
> on disallowing suspensions, but it's kind of a hassle already because 
> of the application of this rule to the whole hierarchy. We'd like for 
> example to have the capability to suspend a subordinate CA that is 
> under investigation or that is pending of an audit, but right now we 
> can't do it... extending these rules to personal certificates is not 
> something I'm personally too enthusiastic.
>
> Best,
> Pedro
>
> El jueves, 2 de mayo de 2019, 17:32:43 (UTC+2), Kathleen Wilson  escribió:
> > Just want to make it very clear to everyone, that the proposal, to 
> > add the following text to section 6 of Mozilla's Root Store Policy 
> > would mean that certs constrained to id-kp-emailProtection 
> > (end-entity and intermediate), i.e. S/MIME certs, would be subject 
> > to the same BR rules and revocation timelines as TLS/SSL certs.
> >
> > > This requirement applies to certificates that are not otherwise
> required
> > >> to comply with the BRs.
> >
> > For example, Section 4.9.1.1 of the BRs says:
> > ""
> > MUST revoke a Certificate within 5 days if one or more of the 
> > following
> > occurs: ...
> >
> > 1. The Certificate no longer complies with the requirements of 
> > Sections
> > 6.1.5 and 6.1.6;
> >  ...
> > 7. The CA is made aware that the Certificate was not issued in 
> > accordance with these Requirements ""
> >
> > I interpret "these Requirements" to mean the BRs. Therefore, my 
> > interpretation of the proposed additional text is that certs that 
> > are constrained to S/MIME would also have to be issued in full 
> > accordance with the BRs and would have to be revoked within the 
> > timeline as specified in the BRs when found to be not in full 
> > compliance with the BR issuance rules.
> >
> > Section 1.1 of Mozilla's root store policy limits the scope of the 
> > policy such that the proposed additional text would only 
> > specifically add the rules to S/MIME certs. Certs with no EKU 
> > extension or anyExtendedKeyUsage are considered technically capable 
> > of issuing TLS certs, so already subject to the rules of the BRs.
> >
> > Therefore, my concern is that the proposed additional text would 
> > mean that all of the BR issuance rules and revocation rules would 
> > also apply to S/MIME certs. I do not think that S/MIME certs have 
> > been taken into account in the BRs, so I do not think we should 
> > impose all the BR issuance and revocation rules on S/MIME certs.
> >
> > Kathleen
> ___
> 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-

Re: DarkMatter Concerns

2019-05-06 Thread galen.b.stephenson--- via dev-security-policy
Greetings,

I'm basing my opinion on EFF's article (RE: 
https://www.eff.org/deeplinks/2019/02/cyber-mercenary-groups-shouldnt-be-trusted-your-browser-or-anywhere-else).
  I submit that EFF makes valid points and I agree with their assessment.  
DarkMatter appears to be a threat actor and should not be given any position of 
trust regarding certificate authority.

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