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-