Re: Policy 2.7 Proposal: Incident Reporting Updates

[Ryan Sleevi via dev-security-policy]

On Tue, Oct 22, 2019 at 9:51 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I have added this proposal to the 2.7 branch:
>
> https://github.com/mozilla/pkipolicy/commit/fa843039285b10030490c7eb54d1b754edae1fbc
>
> I will greatly appreciate everyone's feedback on these changes.


This is almost entirely on the typographical side:
items 1-4 use ; at the end of line. Item 5 uses "; and", and item 6 ends
with "."

If the desire is to keep that structure, then I think the following changes
are needed:
- item 5 has "; and" changed to ";"
- item 6 has "." changed to "; and"
- Item 7 has "Ensure" changed to "ensure"
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

Having received no comments, I did not add the proposed guidance on status
update frequency, but I did make the "marked as resolved" change that
Jeremy suggested:
https://github.com/mozilla/pkipolicy/commit/bad3fedc10e1fe9d5237760093ad235326e3bd62

An additional related change has been proposed in issue #193 [1]: require
incident disclosure transitively for all sub-CAs. In the issue, it was
pointed out that  the expectations for incident reporting by subordinate
CAs might not be clear, and a number of options were presented. I proposed
that the most important point to make in policy is that Mozilla holds the
program member (i.e. root CA) accountable.

Ryan suggested the following addition to the list of requirements in
section 2.1 to clarify this requirement:

The CA whose certificates are included in Mozilla's root program MUST
ensure that all certificates within the scope of this policy, as described
in Section 1.1, adhere to this policy.

I have added this proposal to the 2.7 branch:
https://github.com/mozilla/pkipolicy/commit/fa843039285b10030490c7eb54d1b754edae1fbc

I will greatly appreciate everyone's feedback on these changes.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/193

On Fri, Oct 4, 2019 at 4:22 PM Wayne Thayer  wrote:

> Jeremy Rowley posted the following comments in a separate thread:
>
> One suggestion on incident reports is to define "regularly update" as some
>> period of time as non-responses can result in additional incident reports.
>> Maybe something along the lines of "the greater of every 7 days, the time
>> period specified in the next update field by Mozilla, or the time period
>> for the next update as agreed upon with Mozilla". I'd also change "the
>> corresponding bug is resolved by a Mozilla representative" to "the
>> corresponding bug is marked as resolved in bugzilla by a Mozilla
>> representative" since the CA is resolving the actual bug, and Mozilla is
>> managing its perception on the bug's status.
>>
>
> While I agree with the intent, I do fear that something this strict in
> policy creates the wrong incentives (e.g. bots that auto-comment bugs with
> no real updates, and others that create new incidents after 7 days and one
> second). I'd be okay with adding something like "CAs SHOULD update status
> weekly and MUST provide status updates at least every 30 days unless
> otherwise agreed by a Mozilla representative."
>
> The addition of "marked as resolved" makes sense to me.
>
> On Tue, Apr 23, 2019 at 4:15 PM Wayne Thayer  wrote:
>
>>
>> On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer 
>> wrote:
>>
>>>
>>> I've drafted a specific proposal for everyone's consideration:
>>>
>>>
>>> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>>>
>>>
>> Having received no new comments on this proposal, I'll consider this
>> issue closed and plan to include it in policy version 2.7.
>>
>> - Wayne
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi  wrote:

>
> On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> > I'm also not sure if I understand the wording correctly. Let's assume,
>> an
>> > internal CA of company "mycompany" gets successfully validated for
>> > mycompany.example and receives a (possibly name constrained) certificate
>> > for its issuing CA from one of the root CAs. Can this internal CA issue
>> > certificates for every email address under @mycompany.example without
>> > further validation or is an internal validation process required? My
>> > opinion is, that such an internal validation process doesn't increase
>> > security, since mycompany controls the mailservers of mycompany and can
>> > anyhow validate everything.
>> >
>> >
>> Thanks Dimitris and Rufus. Would it satisfy your concern if the
>> requirement
>> was changed to:
>>
>> The CA SHALL NOT delegate validation of the Base Domain Name (as defined
>> in
>> the Baseline Requirements) portion of an email address.
>>
>
> I may be misunderstanding Rufus' concern, but it seemed slightly different?
>
> That is, taken in the whole of 2.2, the expectation is "the CA takes
> reasonable measures to verify that the entity submitting the request
> controls the email account associated with the email address referenced in
> the certificate *or* has been authorized by the email account holder to act
> on the account holder's behalf".
>
> If the CA has validated "mycompany.example", associated with account
> "mycompany", what is the expectation for 'localpart'?
>
> Interpretation 1) The CA MAY delegate validation of the localpart to
> 'mycompany'. However, 'mycompany' MUST take reasonable measure ...
> Interpretation 2) By validating 'mycompany' as to have control over
> 'mycompany.example', the CA has taken reasonable measure. No further
> validation requirements exist for the localpart, provided it is directed by
> the 'mycompany' account, as 'mycompany' is seen to implicitly have control
> over the MX records.
>
> I'm not sure Interpretation #2 fully holds (e.g. if the CA were using
> something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was
> trying to get at whether (CA || mycompany) needs to perform some validation
> step for 'localpart' once the validation for the domain part is done.
>
>
The "new" (it was already a Forbidden Practice) restriction on delegating
domain validation doesn't change the language that applies here, which is
that "...the CA takes reasonable measures..." and that "The CA's CP/CPS
must clearly specify the procedure(s)...". Until there are BRs for S/MIME,
CAs must define and document their email validation practices.

  As to Dimitris' case, I think you're spot on in understanding the problem.
>
>
>> Alternately, would this create an unacceptable loophole in the requirement
>> and if so, can you suggest a more secure alternative?
>
>
> My worry is that CAs will read this believing it permits more than
> intended. If the CA doesn't use "Base Domain Name" / "Authorization Domain
> Name", and only validates at the FQDN (i.e. the entire @domain), they may
> see this as being permitted to delegate. After all, they are not delegating
> validation of a Base Domain Name, they're delegating validation of an FQDN.
>
> """The CA SHALL NOT delegate validation of the domain portion of an email
> address. The CA MAY rely on validation the CA has performed for an
> Authorization Domain Name (as specified in the Baseline Requirements) as
> being valid for subdomains of that Authorization Domain Name."""
>
>
This is much better, thanks. The proposed change is:
https://github.com/mozilla/pkipolicy/commit/0a63f457c059365103e48ad3eb409cd376903e51

The point here is to make it explicit SHALL NOT. The following sentence
> does not conflict or limit that scope, but gives the CA limited additional
> permission to address the case Dimitris raised.
>
> The choice of "Authorization Domain Name" versus "Base Domain Name" is
> that a given FQDN may have multiple "Base Domain Names", due to how the
> Public Suffix List works. The Authorization Domain Name process was
> designed to find the most specific Base Domain Name, by pruning labels
> left-to-right. Rather than recreate that algorithm, I reused it here.
>
> The downside is that such a definition picks up CNAME chasing, which
> (similar to the remarks to Rufus), can be distinct from MX validation in
> some situations. However, it's a trade-off, and seems strictly improved
> over the status quo, and regardless, the documentation requirement that 2.2
> places would cover those situations (hopefully).
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox removes UI for site identity

[Wayne Thayer via dev-security-policy]

The primary purpose of forwarding the Intent to Ship email to this list was
to inform the community of this planned change and the reasoning behind it.
Mozilla considered lots of information prior to announcing the change, and
during the vigorous debate that ensued, we continued to listen without
taking sides. In the end, the discussion and information presented did not
compel us to change our decision.

On Tue, Oct 22, 2019 at 4:49 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, Oct 22, 2019 at 03:35:52PM -0700, Kirk Hall via
> dev-security-policy wrote:
> > I also have a question for Mozilla on the removal of the EV UI.
>
> This is a mischaracterisation.  The EV UI has not been removed, it has been
> moved to a new location.
>
> > So my question to Mozilla is, why did Mozilla post this as a subject on
> > the mozilla.dev.security.policy list if it didn't plan to interact with
> > members of the community who took the time to post responses?
>
> What leads you to believe that Mozilla didn't plan to interact with members
> of the community?  It is entirely plausible that if any useful responses
> that warranted interaction were made, interaction would have occurred.
>
> I don't believe that Mozilla is obliged to respond to people who have
> nothing useful to contribute, and who don't accurately describe the change
> being made.
>
> > This issue started with a posting by Mozilla on August 12, but despite
> 237
> > subsequent postings from many members of the Mozilla community, I don't
> > think Mozilla staff ever responded to anything or anyone - not to explain
> > or justify the decision, not to argue.  Just silence.
>
> I think the decision was explained and justified in the initial
> announcement.  No information that contradicted the provided justification
> was presented, so I don't see what argument was required.
>
> > In the future, if Mozilla has already made up its mind and is not
> > interested in hearing back from the community, it might be better NOT to
> > start a discussion on the list soliciting feedback.
>
> Soliciting feedback and hearing back from the community does not require
> response from Mozilla, merely reading.  Do you have any evidence that
> Mozilla staff did not, in fact, read the feedback that was given?
>
> - Matt
>
> ___
> 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: Firefox removes UI for site identity

[Matt Palmer via dev-security-policy]

On Tue, Oct 22, 2019 at 03:35:52PM -0700, Kirk Hall via dev-security-policy 
wrote:
> I also have a question for Mozilla on the removal of the EV UI.

This is a mischaracterisation.  The EV UI has not been removed, it has been
moved to a new location.

> So my question to Mozilla is, why did Mozilla post this as a subject on
> the mozilla.dev.security.policy list if it didn't plan to interact with
> members of the community who took the time to post responses?

What leads you to believe that Mozilla didn't plan to interact with members
of the community?  It is entirely plausible that if any useful responses
that warranted interaction were made, interaction would have occurred.

I don't believe that Mozilla is obliged to respond to people who have
nothing useful to contribute, and who don't accurately describe the change
being made.

> This issue started with a posting by Mozilla on August 12, but despite 237
> subsequent postings from many members of the Mozilla community, I don't
> think Mozilla staff ever responded to anything or anyone - not to explain
> or justify the decision, not to argue.  Just silence.

I think the decision was explained and justified in the initial
announcement.  No information that contradicted the provided justification
was presented, so I don't see what argument was required.

> In the future, if Mozilla has already made up its mind and is not
> interested in hearing back from the community, it might be better NOT to
> start a discussion on the list soliciting feedback.

Soliciting feedback and hearing back from the community does not require
response from Mozilla, merely reading.  Do you have any evidence that
Mozilla staff did not, in fact, read the feedback that was given?

- Matt

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

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > I'm also not sure if I understand the wording correctly. Let's assume, an
> > internal CA of company "mycompany" gets successfully validated for
> > mycompany.example and receives a (possibly name constrained) certificate
> > for its issuing CA from one of the root CAs. Can this internal CA issue
> > certificates for every email address under @mycompany.example without
> > further validation or is an internal validation process required? My
> > opinion is, that such an internal validation process doesn't increase
> > security, since mycompany controls the mailservers of mycompany and can
> > anyhow validate everything.
> >
> >
> Thanks Dimitris and Rufus. Would it satisfy your concern if the requirement
> was changed to:
>
> The CA SHALL NOT delegate validation of the Base Domain Name (as defined in
> the Baseline Requirements) portion of an email address.
>

I may be misunderstanding Rufus' concern, but it seemed slightly different?

That is, taken in the whole of 2.2, the expectation is "the CA takes
reasonable measures to verify that the entity submitting the request
controls the email account associated with the email address referenced in
the certificate *or* has been authorized by the email account holder to act
on the account holder's behalf".

If the CA has validated "mycompany.example", associated with account
"mycompany", what is the expectation for 'localpart'?

Interpretation 1) The CA MAY delegate validation of the localpart to
'mycompany'. However, 'mycompany' MUST take reasonable measure ...
Interpretation 2) By validating 'mycompany' as to have control over
'mycompany.example', the CA has taken reasonable measure. No further
validation requirements exist for the localpart, provided it is directed by
the 'mycompany' account, as 'mycompany' is seen to implicitly have control
over the MX records.

I'm not sure Interpretation #2 fully holds (e.g. if the CA were using
something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was
trying to get at whether (CA || mycompany) needs to perform some validation
step for 'localpart' once the validation for the domain part is done.

  As to Dimitris' case, I think you're spot on in understanding the problem.


> Alternately, would this create an unacceptable loophole in the requirement
> and if so, can you suggest a more secure alternative?


My worry is that CAs will read this believing it permits more than
intended. If the CA doesn't use "Base Domain Name" / "Authorization Domain
Name", and only validates at the FQDN (i.e. the entire @domain), they may
see this as being permitted to delegate. After all, they are not delegating
validation of a Base Domain Name, they're delegating validation of an FQDN.

"""The CA SHALL NOT delegate validation of the domain portion of an email
address. The CA MAY rely on validation the CA has performed for an
Authorization Domain Name (as specified in the Baseline Requirements) as
being valid for subdomains of that Authorization Domain Name."""

The point here is to make it explicit SHALL NOT. The following sentence
does not conflict or limit that scope, but gives the CA limited additional
permission to address the case Dimitris raised.

The choice of "Authorization Domain Name" versus "Base Domain Name" is that
a given FQDN may have multiple "Base Domain Names", due to how the Public
Suffix List works. The Authorization Domain Name process was designed to
find the most specific Base Domain Name, by pruning labels left-to-right.
Rather than recreate that algorithm, I reused it here.

The downside is that such a definition picks up CNAME chasing, which
(similar to the remarks to Rufus), can be distinct from MX validation in
some situations. However, it's a trade-off, and seems strictly improved
over the status quo, and regardless, the documentation requirement that 2.2
places would cover those situations (hopefully).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox removes UI for site identity

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 1:38 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks Johann. Much appreciated. Would you be kind enough to email me a
> screen shot to save me the trouble of installing an older version and then
> waiting for an update? :)
>
>
You can find the (now updated) release notes at
https://www.mozilla.org/en-US/firefox/70.0/releasenotes/

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

Re: Firefox removes UI for site identity

[Kirk Hall via dev-security-policy]

I also have a question for Mozilla on the removal of the EV UI.  This issue 
started with a posting by Mozilla on August 12, but despite 237 subsequent 
postings from many members of the Mozilla community, I don't think Mozilla 
staff ever responded to anything or anyone - not to explain or justify the 
decision, not to argue.  Just silence.

So my question to Mozilla is, why did Mozilla post this as a subject on the 
mozilla.dev.security.policy list if it didn't plan to interact with members of 
the community who took the time to post responses?

In the future, if Mozilla has already made up its mind and is not interested in 
hearing back from the community, it might be better NOT to start a discussion 
on the list soliciting feedback.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 10:59 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > > Sounds good. This was your proposed response to solving this issue
> > > back on May 13, so it's full circle :)
> > >
> > >
> > > I'm going to consider this issue resolved unless there are further
> > > comments.
> >
> > Just checking whether the following is acceptable.
> >
> > If a CA validates the domain mycompany.example being owned/controlled by
> "mycompany", can this company delegate the issuance of
> > S/MIME certificates for subsection1.mycompany.example to an internal
> department or a subsidiary? Does the proposed language allow
> > this?
>
> I'm also not sure if I understand the wording correctly. Let's assume, an
> internal CA of company "mycompany" gets successfully validated for
> mycompany.example and receives a (possibly name constrained) certificate
> for its issuing CA from one of the root CAs. Can this internal CA issue
> certificates for every email address under @mycompany.example without
> further validation or is an internal validation process required? My
> opinion is, that such an internal validation process doesn't increase
> security, since mycompany controls the mailservers of mycompany and can
> anyhow validate everything.
>
>
Thanks Dimitris and Rufus. Would it satisfy your concern if the requirement
was changed to:

The CA SHALL NOT delegate validation of the Base Domain Name (as defined in
the Baseline Requirements) portion of an email address.

Alternately, would this create an unacceptable loophole in the requirement
and if so, can you suggest a more secure alternative?

By the way: How are CAA records to be treated in the scope of S/MIME? Since
> gmail.com has a CAA record that prevents every CA except of Google to
> issue certificates for gmail.com, does this also forbid every CA to issue
> certificates for rufus.busch...@gmail.com?
>
>
I'm not aware of any current policy that requires CAs to perform CAA checks
on S/MIME certificates.

With best regards,
> Rufus Buschart
>
> Siemens AG
> Siemens Operations
> Information Technology
> Value Center Core Services
> SOP IT IN COR
> Freyeslebenstr. 1
> 91058 Erlangen, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> www.twitter.com/siemens
>
> www.siemens.com/ingenuityforlife
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief
> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel,
> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and
> Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300,
> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>
> ___
> 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:Extend Section 8 to Encompass Subordinate CAs

[Wayne Thayer via dev-security-policy]

I made a change to the new section 8.1 language intended to include in the
scope both the transfer of existing subordinate CA certificates and the
signing of new subordinate CA certificates that are controlled by an
organization other than the CA:
https://github.com/mozilla/pkipolicy/commit/e3da5aa27bfa02c73b3c474a3aa0420623999333

"Obtains control of" is language that we already use in section 8.

For now, I'd like to allow organizations that currently control a
subordinate CA certificate to be grandfathered in, and the current proposal
does that. The proposals to further strengthen these requirements by
requiring public discussion for organizations already in control of a subCA
are now documented in issue #195 [1].

Regarding the potentially unclear requirement that notifications are made
via email to certifica...@mozilla.org, I'm open to trying to clarify this,
but we're not ready to move the notifications into CCADB. I've created
issue #149 [2] to track that as a future change.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/195
[2] https://github.com/mozilla/pkipolicy/issues/194

On Fri, Oct 4, 2019 at 5:18 PM Jeremy Rowley 
wrote:

> I did flag that part as wearing my personal hat .
>
>
>
> The Trust Italia Sub CA is an example of where confusion may arise in the
> policy and where the complexity arises in these relationships. This was not
> necessarily a “new” CA from what I understood. This is also why I qualified
> the shut down in 2020 as the non-browser TLS. We aren’t expanding the sub
> CAs beyond what exists while we figure out what to do with existing
> infrastructures that are using them.
>
>
>
> That said, still wearing a personal hat, I do think the community should
> have access to this information and review the entities that transitively
> chain up to the Mozilla root program for sMIME or TLS. There should be a
> review of all these sub CAs, including the Trust Italia one we replaced.
> The only reason I can see grandfathering is if there are too many to review
> at one time. Then grandfather the new ones and review before a new CA is
> required to issue. That’ll spur CAs to bring the on-prem Sub CAs forward
> for review.
>
>
>
> The bigger question to me, is how should this review take place? Should
> the root CA sponsor the sub CA and talk about the infrastructure and
> operations? I think there should be an established process of how this
> occurs, and the process is probably slightly different than roots because
> of the extra party (root CA) involved.
>
>
>
> *From:* Wayne Thayer 
> *Sent:* Friday, October 4, 2019 12:40 PM
> *To:* Jeremy Rowley 
> *Cc:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Re: Policy 2.7 Proposal:Extend Section 8 to Encompass
> Subordinate CAs
>
>
>
> Thanks Jeremy.
>
>
>
> On Thu, Oct 3, 2019 at 5:06 PM Jeremy Rowley 
> wrote:
>
> Hey Wayne,
>
> I think there might be confusion on how the notification is supposed to
> happen. Is notification through CCADB sufficient? We've uploaded all of the
> Sub CAs to CCADB including the technically constrained ICAs. Each one that
> is hosted/operated by itself is marked that way using the Subordinate CA
> Owner field. Section 8 links to emailing certifica...@mozilla.org but
> operationally, CCADB has become the default means of providing this notice.
> If you're expecting email, that may be worth clarifying in case CAs missed
> that an email is required. I know I missed that, and because CCADB is the
> common method of notification there is a chance that notice was considered
> sent but not in the expected way.
>
>
>
> Considering that section 8 links to an email address where it states "MUST 
> notify
> Mozilla ", I'm skeptical that there is
> confusion, but I do agree that it makes sense for the notification to be
> triggered via an update to CCADB rather than an email. I'll look in to this.
>
>
>
> There's also confusion over the "new to Mozilla" language I think. I
> interpreted this language as organizations issued cross-signs after the
> policy. For example, Siemens operated a Sub CA through Quovadis prior to
> policy date so they aren't "new" to the CA space even if they were
> re-certified.
>
>
>
> That's the correct interpretation, barring any further clarifications...
>
>
>
> However, they would be new in the sense you identified - they haven't gone
> through an extensive review by the community.  If the goal is to ensure the
> community review happens for each Sub CA, then requiring all
> recertifications to go through an approval process makes sense instead of
> making an exception for new. I'm not sure how many exist currently, but if
> there are not that many organizations, does a grandfathering clause cause
> unnecessary complexity? I realize this is not in DigiCert's best interest,
> but the community may benefit the most by simply requiring a review of all
> Sub CAs instead of trying to grandfather in existing cross-signs.  Do you
> have an 

Re: Firefox removes UI for site identity

[Paul Walsh via dev-security-policy]

Thanks Johann. Much appreciated. Would you be kind enough to email me a screen 
shot to save me the trouble of installing an older version and then waiting for 
an update? :)

Thanks,
- Paul


> On Oct 22, 2019, at 1:29 PM, Johann Hofmann  wrote:
> 
> Hi Paul,
> 
> thanks for the heads up. This wasn't intentional and I've reached out to get 
> the security UI changes added to the release notes for 70. You're right that 
> this is significant enough to be included. The page should be updated very 
> soon, so that most users will see the new version (due to throttled rollouts 
> and a general delay in users updating).
> 
> Cheers,
> 
> Johann
> 
> On Tue, Oct 22, 2019 at 9:06 PM Paul Walsh via dev-security-policy 
>  > wrote:
> Directly question for Mozilla. 
> 
> Today, the website identity UI was removed from Firefox. “We" new it was 
> coming. But millions of users didn’t. 
> 
> Why wasn’t this mentioned in the release notes on the page that’s 
> automatically opened following the update? 
> 
> Someone might say “they didn’t know it was there anyway”. While this is true 
> for the vast majority, it doesn’t answer my question. And it’s not 100% 
> accurate for every user of Firefox. 
> 
> It’s significant enough to warrant being mentioned in my opinion. And a blog 
> post doesn’t count. 
> 
> Thanks,
> - Paul
> 
> ___
> 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: Firefox removes UI for site identity

[Johann Hofmann via dev-security-policy]

Hi Paul,

thanks for the heads up. This wasn't intentional and I've reached out to
get the security UI changes added to the release notes for 70. You're right
that this is significant enough to be included. The page should be updated
very soon, so that most users will see the new version (due to throttled
rollouts and a general delay in users updating).

Cheers,

Johann

On Tue, Oct 22, 2019 at 9:06 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Directly question for Mozilla.
>
> Today, the website identity UI was removed from Firefox. “We" new it was
> coming. But millions of users didn’t.
>
> Why wasn’t this mentioned in the release notes on the page that’s
> automatically opened following the update?
>
> Someone might say “they didn’t know it was there anyway”. While this is
> true for the vast majority, it doesn’t answer my question. And it’s not
> 100% accurate for every user of Firefox.
>
> It’s significant enough to warrant being mentioned in my opinion. And a
> blog post doesn’t count.
>
> Thanks,
> - Paul
>
> ___
> 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

Firefox removes UI for site identity

[Paul Walsh via dev-security-policy]

Directly question for Mozilla. 

Today, the website identity UI was removed from Firefox. “We" new it was 
coming. But millions of users didn’t. 

Why wasn’t this mentioned in the release notes on the page that’s automatically 
opened following the update? 

Someone might say “they didn’t know it was there anyway”. While this is true 
for the vast majority, it doesn’t answer my question. And it’s not 100% 
accurate for every user of Firefox. 

It’s significant enough to warrant being mentioned in my opinion. And a blog 
post doesn’t count. 

Thanks,
- Paul

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

AW: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Buschart, Rufus via dev-security-policy]

> > Sounds good. This was your proposed response to solving this issue
> > back on May 13, so it's full circle :)
> >
> >
> > I'm going to consider this issue resolved unless there are further
> > comments.
> 
> Just checking whether the following is acceptable.
> 
> If a CA validates the domain mycompany.example being owned/controlled by 
> "mycompany", can this company delegate the issuance of
> S/MIME certificates for subsection1.mycompany.example to an internal 
> department or a subsidiary? Does the proposed language allow
> this?

I'm also not sure if I understand the wording correctly. Let's assume, an 
internal CA of company "mycompany" gets successfully validated for 
mycompany.example and receives a (possibly name constrained) certificate for 
its issuing CA from one of the root CAs. Can this internal CA issue 
certificates for every email address under @mycompany.example without further 
validation or is an internal validation process required? My opinion is, that 
such an internal validation process doesn't increase security, since mycompany 
controls the mailservers of mycompany and can anyhow validate everything.

By the way: How are CAA records to be treated in the scope of S/MIME? Since 
gmail.com has a CAA record that prevents every CA except of Google to issue 
certificates for gmail.com, does this also forbid every CA to issue 
certificates for rufus.busch...@gmail.com? 

With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322



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 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Dimitris Zacharopoulos via dev-security-policy]

On 2019-10-22 7:28 μ.μ., Wayne Thayer wrote:


The CA SHALL NOT delegate validation of the domain part of
an e-mail
address.


This is

https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a


Sounds good. This was your proposed response to solving this issue
back on May 13, so it's full circle :)


I'm going to consider this issue resolved unless there are further 
comments.


Just checking whether the following is acceptable.

If a CA validates the domain mycompany.example being owned/controlled by 
"mycompany", can this company delegate the issuance of S/MIME 
certificates for subsection1.mycompany.example to an internal department 
or a subsidiary? Does the proposed language allow this?



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

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Mon, Oct 21, 2019 at 7:01 PM Ryan Sleevi  wrote:

>
> On Mon, Oct 21, 2019 at 7:58 PM Wayne Thayer  wrote:
>
>> The CA MUST verify all e-mail addresses using a process that is
>>> substantially similar to the process used to verify domain names, as
>>> described in the Baseline Requirements.
>>>
>>
>> This seems problematic because it could be interpreted as forbidding an
>> email challenge-response validation, not to mention that "substantially"
>> leaves a lot of room for interpretation.
>>
>
> Yeah, this was more about short-hand matching the existing 2.2
> requirements for validation, which leave "reasonable measures" as the
> validation requirement (i.e. even more room for interpretation ;D)
>
>
>> The CA SHALL NOT delegate validation of the domain part of an e-mail
>>> address.
>>>
>>
>> This is
>> https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a
>>
>
> Sounds good. This was your proposed response to solving this issue back on
> May 13, so it's full circle :)
>
>

I'm going to consider this issue resolved unless there are further comments.


>> The CA SHALL NOT delegate validation of the local part of an e-mail
>>> address
>>> except when delegating to an Enteprise RA, provided that the domain part
>>> of
>>> the e-mail address is within the Enteprise RA's verified Domain
>>> Namespace.
>>>
>>>
>> This seems to go beyond the original intent of this issue and the
>> discussion to-date, and Enterprise RAs are not defined in the context of
>> S/MIME certificates. Why is the existing language in section 2.2(2)
>> insufficient to cover this requirement?
>>
>
> Your original proposal seemed to entirely do away with this ("Delegating
> this function to 3rd parties is not permitted."). I was trying to capture
> the subset for the use case folks identified (including my initial reply to
> your proposal, back on May 13), while still being more prescriptive.
>
> The issue/concern would be a CA reads that they shall not delegate the
> domain portion, but don't realize it /also/ means they can't delegate
> 'total' validation, since the full e-mail also contains a domain part. i.e.
> that I can't delegate validating sleevi.example, but I can totally delegate
> validating ryan@sleevi.example since that's not delegating "just" a
> domain part, but delegating validation a "total" email.
>
> It's contrived, I agree, but it was trying to match your original, much
> more restrictive language, of not allowing any delegation of e-mail.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy