Thank you for the comments Dimitris. I think you make a valid point in general that S/MIME certificates are quite different from TLS certificates, and applying the BR rules to them might not be appropriate. I expect this to ultimately be sorted out by the CAB Forum's future S/MIME Working Group, but in the interim we still need some reasonable Mozilla policy. This leads me to conclude that the best solution might be to do as Kathleen suggested and reinstate the old Mozilla revocation requirements (prior to referencing the BRs) to apply to S/MIME certificates: https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation The biggest change here from my earlier proposal would be that no revocation timeline would be specified.
I also suggest that we add a requirement for both TLS and S/MIME certificates that states the CA must revoke a certificate that "does not comply with the version of this policy that was in effect at the time it was issued.". Currently, there is no hard requirement for CAs to revoke certificates that comply with the BRs but not with our own policy (e.g. use of the P-521 algorithm [1]). How do these changes sound to everyone? - Wayne [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/4gs5pKqTeK8/_eJvekr1BgAJ On Fri, Jun 14, 2019 at 10:43 PM Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > > Dear Wayne, > > Please consider the fact that S/MIME is focused on "signature" > Certificates which has different considerations than "authentication" > Certificates. The baseline requirements (and their revocation > requirements) are focused on "authentication" Certificates. I believe > the revocation policies, at least for the CA Certificates, do not align > well with S/MIME. > > When a piece of data is "signed" (such as an e-mail), Relying Parties > need to be able to verify the status of the signing Certificate _when > the signature was created_. If the Issuing CA is revoked, it is no > longer able to provide status information for that Certificate. If we > think about the serial number issue, if a CA had to be revoked, status > information for its issued Certificates would discontinue leading > Relying Parties to have difficulties validating the existing signed > e-mails that were valid when signed. > > This might be something to consider more carefully. > > > Thank you, > Dimitris. > > > On 15/5/2019 3:25 π.μ., Wayne Thayer via dev-security-policy wrote: > > On Tue, May 14, 2019 at 11:21 AM Kathleen Wilson via dev-security-policy > < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On 5/10/19 5:46 PM, Wayne Thayer wrote: > >>> I've attempted to update section 6 to incorporate revocation > requirements > >>> for S/MIME certificates: > >>> > >>> > >> > https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637 > >>> Note: since much of this language is copied directly from the BRs, if > we > >>> decide to adopt it, the policy will also need to comply with the > Creative > >>> Commons Attribution 4.0 International license used by the BRs. > >>> > >>> I will greatly appreciate everyone's review and comments on this > proposed > >>> change. > >> > >> The proposed changes look OK to me. > >> > >> But I would also be fine with the new section 6.2 regarding revocation > >> of S/MIME certs just re-using the revocation text that we used to have > >> in our policy (which had been removed in an effort to remove redundancy > >> with the BRs). > >> > >> > >> > https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation > >> > >> > > The 'reasons for revocation' from the old policy are very close to the BR > > language I proposed. The main difference in my proposal is the inclusion > of > > deadlines by which certificates must be revoked (same as in the BRs). > While > > the BR deadlines have sometimes been challenging, I do feel that we're > > better off to have them as our standard and handle exceptions as > incidents, > > so my preference is to stick with my proposal. > > _______________________________________________ > > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
