Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
On Mon, Oct 21, 2019 at 6:49 PM Wayne Thayer wrote: > Here are the proposed changes: > * Reinstate Mozilla's revocation requirements for S/MIME certificates: > https://github.com/mozilla/pkipolicy/commit/e6337bb76a4522da15aeb7c0862b6cc05d317814 > (replacing the original 2.7 proposal with the older Root Store policy > requirements) > * Require revocation when a certificate violates our Root Store policy: > https://github.com/mozilla/pkipolicy/commit/fbe5c4f7b78bd4572632ce411a758eba1acf04ef > (note: I've already fixed the typo) > > I also fixed the list formatting here. Having received no further comments, I will consider these proposals to be accepted. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
Here are the proposed changes: * Reinstate Mozilla's revocation requirements for S/MIME certificates: https://github.com/mozilla/pkipolicy/commit/e6337bb76a4522da15aeb7c0862b6cc05d317814 (replacing the original 2.7 proposal with the older Root Store policy requirements) * Require revocation when a certificate violates our Root Store policy: https://github.com/mozilla/pkipolicy/commit/fbe5c4f7b78bd4572632ce411a758eba1acf04ef (note: I've already fixed the typo) As always, I will appreciate everyone's review or and comments on this proposal. - Wayne On Wed, Oct 2, 2019 at 4:00 PM Wayne Thayer wrote: > 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 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 >> >> ___
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
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 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
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
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
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
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
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
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 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
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. - Wayne On Mon, May 6, 2019 at 2:04 PM Jeremy Rowley wrote: > 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 < > mozilla-dev-security-pol...@lists.mozilla.org> > 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 >
RE: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
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 i
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-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
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
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
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
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
On Fri, Apr 26, 2019 at 5:14 PM Wayne Thayer wrote:
> Section 6 ("Revocation") of Mozilla's Root Store Policy states:
>
> CAs MUST revoke Certificates that they have issued upon the occurrence of
>> any event listed in the appropriate subsection of section 4.9.1 of the
>> Baseline Requirements, according to the timeline defined therein.
>>
>
> Because the BRs don't apply to intermediate and end-entity certificates
> that are constrained to S/MIME, it's not clear if our policy requires that
> those certificates follow the BR revocation requirements or not.
>
> The discussion [1] that led to the current language makes it clear that
> the intent is for the revocation requirement to apply to S/MIME
> certificates.
>
> I propose adding the following statement to clarify the scope of this
> section:
>
> This requirement applies to certificates that are not otherwise required
>> to comply with the BRs.
>
>
> This is https://github.com/mozilla/pkipolicy/issues/166 and
> https://github.com/mozilla/pkipolicy/issues/167
>
>
Kathleen pointed out that I referenced the wrong issues. The correct issues
are:
https://github.com/mozilla/pkipolicy/issues/176 and
https://github.com/mozilla/pkipolicy/issues/177
I will appreciate everyone's input on this proposal.
>
> - Wayne
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/eAy0lxgFHR8/g6Jddy40EAAJ
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
Section 6 ("Revocation") of Mozilla's Root Store Policy states:
CAs MUST revoke Certificates that they have issued upon the occurrence of
> any event listed in the appropriate subsection of section 4.9.1 of the
> Baseline Requirements, according to the timeline defined therein.
>
Because the BRs don't apply to intermediate and end-entity certificates
that are constrained to S/MIME, it's not clear if our policy requires that
those certificates follow the BR revocation requirements or not.
The discussion [1] that led to the current language makes it clear that the
intent is for the revocation requirement to apply to S/MIME certificates.
I propose adding the following statement to clarify the scope of this
section:
This requirement applies to certificates that are not otherwise required to
> comply with the BRs.
This is https://github.com/mozilla/pkipolicy/issues/166 and
https://github.com/mozilla/pkipolicy/issues/167
I will appreciate everyone's input on this proposal.
- Wayne
[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/eAy0lxgFHR8/g6Jddy40EAAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
