Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of December 2020 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 1 Dec 2020 15:00:43 + (GMT)

CA Owner: Government of The Netherlands, PKIoverheid (Logius)
   - Certificate Name: UZI-register Medewerker niet op naam CA G3
SHA-256 Fingerprint: 
972957304031234ED17679FDCB97556D6173D5F2BF0E6E66D612680CA6E77685

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Medewerker op naam CA G3
SHA-256 Fingerprint: 
D28DB435E31212A3BDCCF87620F6544B99A9C02328BF983E882FD0627A1D130F

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Zorgverlener CA G3
SHA-256 Fingerprint: 
507DB60D263D3D09D283DE2E3AA435DFD8775E52BC335702E3832BBB57EC1CBD

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Medewerker op naam CA G3
SHA-256 Fingerprint: 
D8553A2880E96B7AA4C7413DD903AFD3D580504695DD26A168FD48CCE7B1474A

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Zorgverlener CA G3
SHA-256 Fingerprint: 
3EAD4F72F06F1054881D2728DE033A8E13FADE6BD165084018EB943C17378DAA

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Medewerker niet op naam CA G3
SHA-256 Fingerprint: 
38DED3FF6827579008AF4887EB9698A3CFA927FA8ED59F06BA090FB9A63E2D77

Standard Audit Period End Date (mm/dd/): 08/31/2019



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

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

[Ryan Sleevi via dev-security-policy]

On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> See responses inline below:
>
> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie 
> 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
>  > 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

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

[Doug Beattie via 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 .  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

-Original Message-
From: dev-security-policy  On 
Behalf Of Ben Wilson via dev-security-policy
Sent: Monday, November 30, 2020 2:27 PM
To: mozilla-dev-security-policy 
Subject: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name 
verification to 398 days

 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  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

See responses inline below:

On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie 
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  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


>
> Doug
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ben Wilson via dev-security-policy
> Sent: Monday, November 30, 2020 2:27 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
> verification to 398 days
>
>  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  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
> ___
> 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

Restructuring of the group structure of D-Trust's parent company

[enr...--- via dev-security-policy]

We would like to inform you that a restructuring of the group structure of our 
parent company, which owns 100 percent of D-Trust GmbH, is planned for December 
2020. This restructuring has a purely formal character. However, for the sake 
of good order, we would like to report on it here. 
 
First of all: There will be no changes in the formal ownership structure of 
D-Trust GmbH. 
 
In detail: today's Bundesdruckerei GmbH, which already owns 100 percent of 
D-Trust GmbH, will be renamed Bundesdruckerei Gruppe GmbH. The core business of 
the former Bundesdruckerei GmbH will be transferred to Bundesdruckerei Gruppe 
GmbH’s daughter company BIS Bundesdruckerei International Services GmbH and 
this company will subsequently be renamed Bundesdruckerei GmbH. This entire 
process has no effect on D-Trust GmbH, as it will continue to be owned by 
Bundesdruckerei Gruppe GmbH (formerly Bundesdruckerei GmbH). All acting persons 
at D-Trust GmbH as well as at Bundesdruckerei Gruppe GmbH remain the same. The 
ownership of Bundesdruckerei Gruppe GmbH will not change. This remains the 
German state, represented by the German Federal Ministry of Finance.

Thanks,
Enrico Entschew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy