Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

781 views
Skip to first unread message

Ben Wilson

unread,
Nov 30, 2020, 2:27:01 PM11/30/20
to mozilla-dev-security-policy
The purpose of this email is to begin public discussion on a modification
to subsection 5 in section 2.1 of the Mozilla Root Store Policy.

Issue #206 <https://github.com/mozilla/pkipolicy/issues/206> in GitHub
discusses the need to bring the reuse period for domain validation in line
with the certificate issuance validity cycle of 398 days (as set forth in
section 6.3.2 of the Baseline Requirements). This proposal is not to say
that Mozilla is not also contemplating a ballot in the CA/Browser Forum
that would introduce similar language to the Baseline Requirements. Any
potential CABF endorsers of such a ballot should reach out to me off-list.

Currently, subsection 5 of section 2.1 of the Mozilla Root Store Policy
(MRSP) states that a CA must “verify that all of the information that is
included in SSL certificates remains current and correct at time intervals
of 825 days or less;”

It is proposed that a subsection 5.1 be added to this subsection to require
that, for subjectAltName verifications of dNSNames or IPAddresses performed
on or after July 1, 2021, CAs verify the dNSName or IPAddress at intervals
of 398 days or less.
Proposed language may be found in the following commit:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/b7b53eea3a0af1503f3c99632ba22efc9e86bee2
Restated here, the proposed language for subsection 5.1 of section 2.1 is:

"for subjectAltName verifications of dNSNames and IPAddresses performed on
or after July 1, 2021, verify that each dNSName or IPAddress is current and
correct at intervals of 398 days or less;"

I look forward to your comments, suggestions and discussions.

Thanks,

Ben

Doug Beattie

unread,
Dec 1, 2020, 1:41:05 PM12/1/20
to Ben Wilson, mozilla-dev-security-policy
Hi Ben,

For now I won’t comment on the 398 day limit or the date which you propose this to take effect (July 1, 2021), but on the ability of CAs to re-use domain validations completed prior to 1 July for their full 825 re-use period. I'm assuming that the 398 day limit is only for those domain validated on or after 1 July, 2021. Maybe that is your intent, but the wording is not clear (it's never been all that clear)

Could you consider changing it to read more like this (feel free to edit as needed):

CAs may re-use domain validation for subjectAltName verifications of dNSNames and IPAddresses done prior to July 1, 2021 for up to 825 days <in accordance with domain validation re-use in the BRs, section 4.2.1>. CAs MUST limit domain re-use for subjectAltName verifications of dNSNames and IPAddresses to 398 days for domains validated on or after July 1, 2021.

>From a CA perspective, I don't have any major concerns with shortening the domain re-use periods, but customers do/will. Will there be a Mozilla blog that outlines the security improvements with cutting the re-use period in half and why July 2021 is the right time?

Doug
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Ben Wilson

unread,
Dec 1, 2020, 2:22:32 PM12/1/20
to Doug Beattie, mozilla-dev-security-policy
See responses inline below:

On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie <doug.b...@globalsign.com>
wrote:

> Hi Ben,
>
> For now I won’t comment on the 398 day limit or the date which you propose
> this to take effect (July 1, 2021), but on the ability of CAs to re-use
> domain validations completed prior to 1 July for their full 825 re-use
> period. I'm assuming that the 398 day limit is only for those domain
> validated on or after 1 July, 2021. Maybe that is your intent, but the
> wording is not clear (it's never been all that clear)
>

Yes. (I agree that the wording is currently unclear and can be improved,
which I'll work on as discussion progresses.) That is the intent - for
certificates issued beginning next July--new validations would be valid for
398 days, but existing, reused validations would be sunsetted and could be
used for up to 825 days (let's say, until Oct. 1, 2023, which I'd advise
against, given the benefits of freshness provided by re-performing methods
in BR 3.2.2.4 and BR 3.2.2.5).


>
> Could you consider changing it to read more like this (feel free to edit
> as needed):
>
> CAs may re-use domain validation for subjectAltName verifications of
> dNSNames and IPAddresses done prior to July 1, 2021 for up to 825 days <in
> accordance with domain validation re-use in the BRs, section 4.2.1>. CAs
> MUST limit domain re-use for subjectAltName verifications of dNSNames and
> IPAddresses to 398 days for domains validated on or after July 1, 2021.
>

Thanks. I am open to all suggestions and improvements to the language. I'll
see how this can be phrased appropriately to reduce the chance for
misinterpretation.


>
> From a CA perspective, I don't have any major concerns with shortening the
> domain re-use periods, but customers do/will. Will there be a Mozilla blog
> that outlines the security improvements with cutting the re-use period in
> half and why July 2021 is the right time?
>

Yes. I'll prepare a blog post that outlines the security improvements to
be obtained by shortening the reuse period. (E.g., certificates should not
contain stale information.) July 2021 was chosen because I figured April
2021 would be too soon. It also allows CAs to schedule any needed system
work during Q2/2021. In my opinion, Oct. 2023 is a considerably long tail
for this change, and existing domains/customers should not be affected
until then.

Cheers,

Ben

Ryan Sleevi

unread,
Dec 1, 2020, 3:34:49 PM12/1/20
to Ben Wilson, Doug Beattie, mozilla-dev-security-policy
On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> See responses inline below:
>
> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie <doug.b...@globalsign.com>
> wrote:
>
> > Hi Ben,
> >
> > For now I won’t comment on the 398 day limit or the date which you
> propose
> > this to take effect (July 1, 2021), but on the ability of CAs to re-use
> > domain validations completed prior to 1 July for their full 825 re-use
> > period. I'm assuming that the 398 day limit is only for those domain
> > validated on or after 1 July, 2021. Maybe that is your intent, but the
> > wording is not clear (it's never been all that clear)
> >
>
> Yes. (I agree that the wording is currently unclear and can be improved,
> which I'll work on as discussion progresses.) That is the intent - for
> certificates issued beginning next July--new validations would be valid for
> 398 days, but existing, reused validations would be sunsetted and could be
> used for up to 825 days (let's say, until Oct. 1, 2023, which I'd advise
> against, given the benefits of freshness provided by re-performing methods
> in BR 3.2.2.4 and BR 3.2.2.5).
>

Why? I have yet to see a compelling explanation from a CA about why
"grandfathering" old validations is good, and as you note, it undermines
virtually every benefit that is had by the reduction until 2023.

Ben, could you explain the rationale why this is better than the simpler,
clearer, and immediately beneficial for Mozilla users of requiring new
validations be conducted on-or-after 1 July 2021? Any CA that had concerns
would have ample time to ensure there is a fresh domain validation before
then, if they were concerned.

Doug, could you explain more about why it's undesirable to do that?


> >
> > Could you consider changing it to read more like this (feel free to edit
> > as needed):
> >
> > CAs may re-use domain validation for subjectAltName verifications of
> > dNSNames and IPAddresses done prior to July 1, 2021 for up to 825 days
> <in
> > accordance with domain validation re-use in the BRs, section 4.2.1>.
> CAs
> > MUST limit domain re-use for subjectAltName verifications of dNSNames and
> > IPAddresses to 398 days for domains validated on or after July 1, 2021.
> >
>
> Thanks. I am open to all suggestions and improvements to the language. I'll
> see how this can be phrased appropriately to reduce the chance for
> misinterpretation.
>

As noted above, I think adopting this wording would prevent much (any?)
benefit from being achieved until 2023. I can understand that 2023 is
better than "never", but I'm surprised to see an agreement so quickly to
that being desirable over 2021. I suspect there's ample context here, but I
think it would benefit from discussion.


> > From a CA perspective, I don't have any major concerns with shortening
> the
> > domain re-use periods, but customers do/will. Will there be a Mozilla
> blog
> > that outlines the security improvements with cutting the re-use period in
> > half and why July 2021 is the right time?

>
>
> Yes. I'll prepare a blog post that outlines the security improvements to
> be obtained by shortening the reuse period. (E.g., certificates should not
> contain stale information.) July 2021 was chosen because I figured April
> 2021 would be too soon. It also allows CAs to schedule any needed system
> work during Q2/2021. In my opinion, Oct. 2023 is a considerably long tail
> for this change, and existing domains/customers should not be affected
> until then.


Right, my concern is that it's "too long" a tail. There's no real benefit
in July 2021 - the benefits aren't really met until Oct 2023.

As we saw with the last change to domain validation, there were a
significant number of CA incidents that resulted from this "grandfather"
approach. Happy to dig them up if it'd be helpful for review/discussion,
but it does seem like the public/Mozilla community has evidence of both it
not being in users best interest, as well as not leading to good compliance
adherence. If there's an argument for why this problematic approach is
still useful, I'm hoping folks can share why.

Equally, we know that once this date is set, there will likely be
substantial opposition from CAs to any further improvements/changes between
July 2021 through to October 2023, since they're "in the midst" of
transitioning. That equally seems a good reason to set an expectation and
with ample lead-time (e.g. 6 months), CAs can work with their customers to
obtain fresh manual validations that are needed, or, if they're security-
and customer- focused, work on automating validation such that such
transitions have zero effective impact on their Subscribers going forward.

I just can't see this approach working in 2020, knowing what we know now,
as well as knowing what the security goals are.

Ben Wilson

unread,
Dec 2, 2020, 4:22:04 PM12/2/20
to Ryan Sleevi, Doug Beattie, mozilla-dev-security-policy
See my responses inline below.
I am open to the idea of cutting off the tail earlier, at let's say,
October 1, 2022, or earlier (see below). I can work on language that does
that.


>
> Ben, could you explain the rationale why this is better than the simpler,
> clearer, and immediately beneficial for Mozilla users of requiring new
> validations be conducted on-or-after 1 July 2021? Any CA that had concerns
> would have ample time to ensure there is a fresh domain validation before
> then, if they were concerned.
>

I don't have anything yet in particular with regard to a
pros-cons/benefits-analysis-supported rationale, except that I expect
push-back from SSL/TLS certificate subscribers and from CAs on their
behalf. You're right, CAs could take the time between now and July 1st to
obtain 398-day validations, but my concern is with the potential push-back.

Also, as I mentioned before, I am interested in proposing this as a ballot
in the CA/Browser Forum and seeing where it goes. I realize that this issue
might come with added baggage from the history surrounding the
validity-period changes that were previously defeated in the Forum, but it
would still be good to see it adopted there first. Nonetheless, this issue
is more than ripe enough to be resolved here by Mozilla as well.



>
> Doug, could you explain more about why it's undesirable to do that?
>
>
>> >
>> > Could you consider changing it to read more like this (feel free to edit
>> > as needed):
>> >
>> > CAs may re-use domain validation for subjectAltName verifications of
>> > dNSNames and IPAddresses done prior to July 1, 2021 for up to 825 days
>> <in
>> > accordance with domain validation re-use in the BRs, section 4.2.1>.
>> CAs
>> > MUST limit domain re-use for subjectAltName verifications of dNSNames
>> and
>> > IPAddresses to 398 days for domains validated on or after July 1, 2021.
>> >
>>
>> Thanks. I am open to all suggestions and improvements to the language.
>> I'll
>> see how this can be phrased appropriately to reduce the chance for
>> misinterpretation.
>>
>
> As noted above, I think adopting this wording would prevent much (any?)
> benefit from being achieved until 2023. I can understand that 2023 is
> better than "never", but I'm surprised to see an agreement so quickly to
> that being desirable over 2021. I suspect there's ample context here, but I
> think it would benefit from discussion.
>

The language needs to be worked on some more. As I note above, we should
come up with a cutoff date that is before 2023. It seems that two years is
too long to wait for the last 825-day validation to expire when there are
domain validation methods that work in a matter of seconds.


>
>
>> > From a CA perspective, I don't have any major concerns with shortening
>> the
>> > domain re-use periods, but customers do/will. Will there be a Mozilla
>> blog
>> > that outlines the security improvements with cutting the re-use period
>> in
>> > half and why July 2021 is the right time?
>
> >
>>
>> Yes. I'll prepare a blog post that outlines the security improvements to
>> be obtained by shortening the reuse period. (E.g., certificates should not
>> contain stale information.) July 2021 was chosen because I figured April
>> 2021 would be too soon. It also allows CAs to schedule any needed system
>> work during Q2/2021. In my opinion, Oct. 2023 is a considerably long tail
>> for this change, and existing domains/customers should not be affected
>> until then.
>
>
> Right, my concern is that it's "too long" a tail. There's no real benefit
> in July 2021 - the benefits aren't really met until Oct 2023.
>

Other options for a cutoff, other than July 2021 or October 2022, could be
December 1, 2021, January 31, 2022, or July 1, 2022.

Ben

Aaron Gable

unread,
Dec 2, 2020, 4:41:20 PM12/2/20
to mozilla-dev-security-policy, Ryan Sleevi, Doug Beattie, Ben Wilson
One potential approach would be to make it so that issuances after July 1,
2021 require a validation no more than 398 days old. The currently-proposed
wording ("verify that each dNSName or IPAddress is current and correct at
intervals of 398 days or less") lends itself to that interpretation, it
just needs to be applied to issuances rather than validations. I would
propose wording like:

5. verify that all of the information that is included in SSL certificates
remains current and correct at intervals of 825 days or less;
5.1. for SSL certificates issued on or after July 1, 2021, verify that each
dNSName or IPAddress is current and correct at intervals of 398 days or
less;

Aaron


On Wed, Dec 2, 2020 at 1:22 PM Ben Wilson via dev-security-policy <

Jeremy Rowley

unread,
Dec 2, 2020, 4:49:43 PM12/2/20
to Ben Wilson, Ryan Sleevi, Doug Beattie, Mozilla
Should this limit on reuse also apply to s/MIME? Right now, the 825 day limit in Mozilla policy only applies to TLS certs with email verification of s/MIME being allowed for infinity time. The first draft of the language looked like it may change this while the newer language puts back the TLS limitation. If it's not addressed in this update, adding clarification on domain verification reuse for SMIME would be a good improvement on the existing policy.

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Ben Wilson via dev-security-policy

Ben Wilson

unread,
Dec 2, 2020, 5:00:59 PM12/2/20
to Jeremy Rowley, Ryan Sleevi, Doug Beattie, Mozilla
All,

I have started a similar, simultaneous discussion with the CA/Browser
Forum, in order to gain traction.

<goog_583396726>
https://lists.cabforum.org/pipermail/servercert-wg/2020-December/002382.html

Ben

On Wed, Dec 2, 2020 at 2:49 PM Jeremy Rowley <jeremy...@digicert.com>
wrote:

Ben Wilson

unread,
Feb 25, 2021, 2:08:11 PM2/25/21
to Mozilla
All,

I continue to move this Issue #206 forward with a proposed change to
section 2.1 of the MRSP (along with an effort to modify section 3.2.2.4 or
section 4.2.1 of the CA/B Forum's Baseline Requirements).

Currently, I am still contemplating adding a subsection 5.1 to MRSP section
2.1 that would read,
" 5.1. for server certificates issued on or after July 1, 2021, verify each
dNSName or IPAddress in a SAN or commonName at an interval of 398 days or
less;"

See draft language here
https://github.com/BenWilson-Mozilla/pkipolicy/commit/69bddfd96d1d311874c35c928abdfc13dc11aba3


Ben

On Wed, Dec 2, 2020 at 3:00 PM Ben Wilson <bwi...@mozilla.com> wrote:

> All,
>
> I have started a similar, simultaneous discussion with the CA/Browser
> Forum, in order to gain traction.
>
> <http://goog_583396726>

Doug Beattie

unread,
Feb 25, 2021, 2:29:50 PM2/25/21
to Ben Wilson, Mozilla
Ben,

I'd prefer that we tie this to a date related to when the domain validations are done, or perhaps 2 statements. As it stands (and as others have commented), on July 1 all customers will immediately need to validate all domains that were done between 825 and 397 days ago, so a huge number all at once for web site owners and for CAs.

I'd prefer that it says " Domain validations performed from July 1, 2021 may be reused for a maximum of 398 days ". I understand that this basically kick the can down the road for an extra year and that may not be acceptable, so, maybe we specify 2 dates:

1) Domain validations performed on or after July 1, 2021 may be reused for a maximum of 398 days.

2) for server certificates issued on or after Feb 1, 2022, each dNSName or IPAddress in a SAN must have been validated within the prior 398 days

Is that a compromise you could consider?

Doug

Ben Wilson

unread,
Feb 25, 2021, 2:41:24 PM2/25/21
to Doug Beattie, Mozilla
Yes - I think we could focus on the domain validations themselves and allow
domain validations to be reused for 398 days (maybe even from December 6,
2019), and then combine that with certificate issuance, but I'm not sure I
like pushing this out to Feb 1, 2022 or even Oct. 1, 2021. Maybe someone
else on the list has a suggested formula?

On Thu, Feb 25, 2021 at 12:29 PM Doug Beattie <doug.b...@globalsign.com>
wrote:

Ryan Sleevi

unread,
Feb 25, 2021, 4:24:36 PM2/25/21
to Doug Beattie, Ben Wilson, Mozilla
On Thu, Feb 25, 2021 at 2:29 PM Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I'd prefer that we tie this to a date related to when the domain
> validations are done, or perhaps 2 statements. As it stands (and as others
> have commented), on July 1 all customers will immediately need to validate
> all domains that were done between 825 and 397 days ago, so a huge number
> all at once for web site owners and for CAs.
>

Isn't this only true if CAs use this discussion period to do nothing?

That is, can't CAs today (or even months ago) have started to more
frequently revalidate their customers, refreshing old validations, helping
transition customers to automated methods, etc?

That is, is the scenario you described inherently bad, or just a
consequence of CA inaction? And is the goal to have zero impact, or, which
your proposal seems to acknowledge, do we agree that some impact is both
reasonable and acceptable, and the only difference would be the degree?

Clint Wilson

unread,
Feb 25, 2021, 7:55:57 PM2/25/21
to Ben Wilson, Mozilla, Doug Beattie
I think it makes sense to separate out the date for domain validation expiration from the issuance of server certificates with previously validated domain names, but agree with Ben that the timeline doesn’t seem to need to be prolonged. What about something like this:

1. Domain name or IP address verifications performed on or after July 1, 2021 may be reused for a maximum of 398 days.
2. Server certificates issued on or after September 1, 2021 must have completed domain name or IP address verification within the preceding 398 days.

This effectively stretches the “cliff” out across ~6 months (now through the end of August), which seems reasonable.

Cheers!
-Clint

> On Feb 25, 2021, at 11:40 AM, Ben Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Yes - I think we could focus on the domain validations themselves and allow
> domain validations to be reused for 398 days (maybe even from December 6,
> 2019), and then combine that with certificate issuance, but I'm not sure I
> like pushing this out to Feb 1, 2022 or even Oct. 1, 2021. Maybe someone
> else on the list has a suggested formula?
>
> On Thu, Feb 25, 2021 at 12:29 PM Doug Beattie <doug.b...@globalsign.com>
> wrote:
>
>> Ben,
>>
>> I'd prefer that we tie this to a date related to when the domain
>> validations are done, or perhaps 2 statements. As it stands (and as others
>> have commented), on July 1 all customers will immediately need to validate
>> all domains that were done between 825 and 397 days ago, so a huge number
>> all at once for web site owners and for CAs.
>>

Ryan Sleevi

unread,
Feb 26, 2021, 11:48:59 AM2/26/21
to mozilla-dev-security-policy, Ben Wilson, Clint Wilson, Doug Beattie
On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I think it makes sense to separate out the date for domain validation
> expiration from the issuance of server certificates with previously
> validated domain names, but agree with Ben that the timeline doesn’t seem
> to need to be prolonged. What about something like this:
>
> 1. Domain name or IP address verifications performed on or after July 1,
> 2021 may be reused for a maximum of 398 days.
> 2. Server certificates issued on or after September 1, 2021 must have
> completed domain name or IP address verification within the preceding 398
> days.
>
> This effectively stretches the “cliff” out across ~6 months (now through
> the end of August), which seems reasonable.
>

Yeah, that does sound reasonable.

Ben Wilson

unread,
Mar 8, 2021, 6:38:53 PM3/8/21
to mozilla-dev-security-policy
All,

Here is the currently proposed wording for subsection 5.1 of MRSP section
2.1:

" 5.1. for server certificates issued on or after October 1, 2021, verify
each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
or less;"

Ben

Doug Beattie

unread,
Mar 16, 2021, 7:21:12 AM3/16/21
to Ben Wilson, mozilla-dev-security-policy
Hi Ben,

Regarding the redlined spec: https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6

Is this a meaningful statement given max validity is 398 days now?
5. verify that all of the information that is included in server certificates remains current and correct at intervals of 825 days or less;
I think we can remove that and them move 5.1 to item 5

I find the words for this requirement 5.1 unclear.

" 5.1. for server certificates issued on or after October 1, 2021, verify each dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;"

Can we say:
"5.1. for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated <in accordance with the CABF Baseline Requirements?> within the prior 398 days.



-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Ben Wilson via dev-security-policy
Sent: Monday, March 8, 2021 6:38 PM
To: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

Ben Wilson

unread,
Mar 16, 2021, 11:10:24 AM3/16/21
to Doug Beattie, mozilla-dev-security-policy
That works, too. Thoughts?

On Tue, Mar 16, 2021 at 5:21 AM Doug Beattie <doug.b...@globalsign.com>
wrote:

Ben Wilson

unread,
Mar 18, 2021, 2:53:20 PM3/18/21
to Doug Beattie, mozilla-dev-security-policy
I've edited the proposed subsection 5.1 and have left section 5 in for
now. See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/d37d7a3865035c958c1cb139b949107665fee232

Doug Beattie

unread,
Mar 19, 2021, 6:45:11 AM3/19/21
to Ben Wilson, mozilla-dev-security-policy
Thanks Ben.



What’s the purpose of this statement:

5. verify that all of the information that is included in server certificates remains current and correct at intervals of 825 days or less;



The BRs limit data reuse to 825 days since March 2018 so I don’t think this adds anything. If it does mean something more than that, can you update to make it more clear?





From: Ben Wilson <bwi...@mozilla.com>
Sent: Thursday, March 18, 2021 2:53 PM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days



I've edited the proposed subsection 5.1 and have left section 5 in for now. See

https://github.com/BenWilson-Mozilla/pkipolicy/commit/d37d7a3865035c958c1cb139b949107665fee232



On Tue, Mar 16, 2021 at 9:10 AM Ben Wilson <bwi...@mozilla.com <mailto:bwi...@mozilla.com> > wrote:

That works, too. Thoughts?



On Tue, Mar 16, 2021 at 5:21 AM Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com> > wrote:

Hi Ben,

Regarding the redlined spec: https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6

Is this a meaningful statement given max validity is 398 days now?
5. verify that all of the information that is included in server certificates remains current and correct at intervals of 825 days or less;
I think we can remove that and them move 5.1 to item 5

I find the words for this requirement 5.1 unclear.

" 5.1. for server certificates issued on or after October 1, 2021, verify each dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;"

Can we say:
"5.1. for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated <in accordance with the CABF Baseline Requirements?> within the prior 398 days.



-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org <mailto:dev-security-...@lists.mozilla.org> > On Behalf Of Ben Wilson via dev-security-policy
Sent: Monday, March 8, 2021 6:38 PM
To: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> >
Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

All,

Here is the currently proposed wording for subsection 5.1 of MRSP section
2.1:

" 5.1. for server certificates issued on or after October 1, 2021, verify each dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;"

Ben

On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi <ry...@sleevi.com <mailto:ry...@sleevi.com> > wrote:

>
>
> On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
> dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:
>
>> I think it makes sense to separate out the date for domain validation
>> expiration from the issuance of server certificates with previously
>> validated domain names, but agree with Ben that the timeline doesn’t
>> seem to need to be prolonged. What about something like this:
>>
>> 1. Domain name or IP address verifications performed on or after July
>> 1,
>> 2021 may be reused for a maximum of 398 days.
>> 2. Server certificates issued on or after September 1, 2021 must have
>> completed domain name or IP address verification within the preceding
>> 398 days.
>>
>> This effectively stretches the “cliff” out across ~6 months (now
>> through the end of August), which seems reasonable.
>>
>
> Yeah, that does sound reasonable.
>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

Ryan Sleevi

unread,
Mar 19, 2021, 12:26:53 PM3/19/21
to Doug Beattie, Ben Wilson, mozilla-dev-security-policy
The S/MIME BRs are not yet a thing, while the current language covers such
CAs (as a condition of Mozilla inclusion)
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Ben Wilson

unread,
Mar 19, 2021, 2:28:13 PM3/19/21
to Ryan Sleevi, Doug Beattie, mozilla-dev-security-policy
Hi Doug,
It means the same thing as in the BRs. I am processing this change on a
parallel track with adding language to the BRs (Ballot SC42) because
neither change is a done deal yet. We'll leave it in for now, not to say
that we won't eventually remove it in a subsequent update.
Thanks,
Ben
0 new messages