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

[Jeremy Rowley via dev-security-policy]

I’m thinking more in terms of the potential rule in the Mozilla policy. If the 
rule is “the CA MUST verify the domain component of the email address” then the 
rule potentially prohibits the scenario where the CA verifies the entire email 
address, not the domain component, by sending a random value to each email 
address and requiring the email address holder to approve issuance. I actually 
liked the previous requirement prohibiting delegation of email address 
verification, although the rule lacked clarity on what email address 
verification entailed. I figure that will be defined in the s/MIME working 
group.

Describing the actors is a good way to look at it though. Besides those three 
buckets of issuers, you have the RAs, the email holders, and the organization 
controlling the domain portion of the email address. These entities may not be 
the same as the CA. More often than not, the RA ends up being the organization 
contracting with the CA for the s/MIME services. The RAs are the risky party 
that I think should be restricted on what they can verify since that’s where 
the lack of transparency starts to come in. With the prohibition against 
delegation of email control eliminated, we’re again placing domain/email 
control responsibilities on a party that has some incentive to misuse it (to 
read email of a third party) without audit, technical, or policy controls that 
limit their authority.  Because there are a lack of controls over the RAs, they 
become a hidden layer in the process that can issue certificates without anyone 
looking at how they are verifying the email address or domain name and whether 
these processes are equivalent to the controls found int eh BR.  Similar to 
TLS, the unaudited party should not be the one providing or verifying 
acceptance of the tokens used to approve issuance.

In short, I’m agreeing with the “at least” verifying the domain control 
portion. However, I know we verify a lot of email addresses directly with the 
email owner that doesn’t have control over the domain name. So the rule should 
be something that permits verification by the root CA of either the full email 
address or the domain name but at least eliminates delegation to non-audited 
third parties. For phrasing, “the CA MUST verify either the domain component of 
the email address or the entire email address using a process that is 
substantially similar to the process used to verify domain names as described 
in the Baseline Requirements”, with the understanding that we will rip out the 
language and replace it with the s/MIME requirements once those are complete at 
the CAB Forum.

Jeremy

From: Ryan Sleevi 
Sent: Friday, October 4, 2019 10:56 PM
To: Jeremy Rowley 
Cc: Kathleen Wilson ; Wayne Thayer ; 
mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for 
S/MIME Certificates

Jeremy:

Could you describe a bit more who the actors are?

Basically, it seems that the actual issuance is going to fall into one of 
several buckets:
1) Root CA controls Issuing CAs key
2) Issuing CA controls its own key, but is technically constrained
3) Issuing CA controls its own key, and is not technically constrained

We know #1 is covered by Root CA’s audit, and we know #3 is covered by Issuing 
CA’s audit, and #2 is technically constrained and thus the domain part is 
apriori validated.

So when you say “some organizations”, I’m trying to understand which of the 
three cases here they fall under. If I understand correctly, the idea is that 
Customer Foo approaches Root CA (Case #1). Root CA knows Foo’s namespace is 
foo.example through prior verification, and Root CA allows Foo to issue to 
*@foo.example. Then Foo says “oh, hey, we have a 
contractor at user@bar.example, we’d like a cert for 
them too”.

Why can’t Root CA verify themselves? Why would or should Root CA trust Foo to 
do it correctly? I can imagine plenty of verification protocols where Foo can 
be the “face” of the verification, but that it uses Root CAs APIs and systems 
under the hood. I‘m fairly certain DigiCert has experience doing this for their 
customers, such as for white label CAs.

So that’s why I’m struggling to understand the use case, or the challenges, 
with at least requiring domain-part validation by the CA.

On Fri, Oct 4, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Will this permit either verification of the email address or the domain part? 
For example, some organizations may verify their entire domain space and then 
confirm contractors using a random value sent to the email address itself. They 
don't  need the entire domain space in those cases, but they do need to issue 
certificates for a few email addresses outside of their domain control. 
Verification of email control using a random value seems like it affords 
controls that are equivalent to the challenge-r

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

[Ryan Sleevi via dev-security-policy]

Jeremy:

Could you describe a bit more who the actors are?

Basically, it seems that the actual issuance is going to fall into one of
several buckets:
1) Root CA controls Issuing CAs key
2) Issuing CA controls its own key, but is technically constrained
3) Issuing CA controls its own key, and is not technically constrained

We know #1 is covered by Root CA’s audit, and we know #3 is covered by
Issuing CA’s audit, and #2 is technically constrained and thus the domain
part is apriori validated.

So when you say “some organizations”, I’m trying to understand which of the
three cases here they fall under. If I understand correctly, the idea is
that Customer Foo approaches Root CA (Case #1). Root CA knows Foo’s
namespace is foo.example through prior verification, and Root CA allows Foo
to issue to *@foo.example. Then Foo says “oh, hey, we have a contractor at
user@bar.example, we’d like a cert for them too”.

Why can’t Root CA verify themselves? Why would or should Root CA trust Foo
to do it correctly? I can imagine plenty of verification protocols where
Foo can be the “face” of the verification, but that it uses Root CAs APIs
and systems under the hood. I‘m fairly certain DigiCert has experience
doing this for their customers, such as for white label CAs.

So that’s why I’m struggling to understand the use case, or the challenges,
with at least requiring domain-part validation by the CA.

On Fri, Oct 4, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Will this permit either verification of the email address or the domain
> part? For example, some organizations may verify their entire domain space
> and then confirm contractors using a random value sent to the email address
> itself. They don't  need the entire domain space in those cases, but they
> do need to issue certificates for a few email addresses outside of their
> domain control. Verification of email control using a random value seems
> like it affords controls that are equivalent to the challenge-response
> mechanisms in the BRs.
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Friday, October 4, 2019 2:38 PM
> To: Kathleen Wilson 
> Cc: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation
> for S/MIME Certificates
>
> I'd like to revive this discussion. So far we've established that the
> existing "required practice" [1] is too stringent for email address
> validation and needs to be changed. We can do that by removing email
> addresses from the scope of the requirement as Kathleen proposed, or by
> exempting the local part of the email address as I proposed earlier:
>
> "CAs MUST NOT delegate validation of the domain name part of an email
> address to a 3rd party."
>
> We have a fairly detailed explanation from Ryan Hurst of why and how
> removing the requirement entirely is beneficial, but no one else has spoken
> in favor of this need. Kathleen did however point out that this requirement
> doesn't appear to be the result of a thorough analysis. We have Ryan Sleevi
> arguing that the process described by Ryan Hurst is insecure and thus a
> reason to forbid delegation of validation of the domain name part. Pedro
> Fuentes also wrote in favor of this outcome.
>
> One thing that might help to resolve this is a more detailed description
> of the weaknesses that are present in the process described by Ryan Hurst.
> If we can all agree that the process is vulnerable, then it seems that we'd
> have a strong argument for banning it.
>
> - Wayne
>
> [1]
>
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
>
>
> On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > > The BRs forbid delegation of domain and IP address validation to
> > > third parties. However, the BRs don't forbid delegation of email
> > > address validation nor do they apply to S/MIME certificates.
> > >
> > > Delegation of email address validation is already addressed by
> > > Mozilla's Forbidden Practices [1] state:
> > >
> > > "Domain and Email validation are core requirements of the Mozilla's
> > > Root Store Policy and should always be incorporated into the issuing
> > > CA's procedures. Delegating this function to 3rd parties is not
> permitted."
> > >
> > > I propose that we move this statement (changing "the Mozilla's Root
> > > Store Policy" to "this policy") into policy section 2.2 "Validation
> Practices".
> > >
> > > This is https://github.com/mozilla/pkipolicy/issues/175
> > >
> > > I will appreciate everyone's input on this proposal.
> > >
> > > - Wayne
> > >
> > > [1]
> > >
> > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegat
> > ion_of_Do

RE: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Jeremy Rowley via dev-security-policy]

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 
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 
mailto:jeremy.row...@digicert.com>> 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 idea on the number that 
might entail? At worst, we waste a bunch of time discovering that all of these 
are perfectly operated and that they could have been grandfathered in the first 
place. At best, we identify some critical issues and resolve them as a 
community.

It appears to be at least 2 dozen organizations, based on the "subordinate CA 
owner" field in CCADB. I say "at least" because, as Dimitris noted, we're just 
now identifying intermediates that are incorrectly labeled as falling under the 
parent certificate's audits.

If there are a significant number of unconstrained on-prem CAs, then language 
that requires a review on re-signing would be helpful.  Perhaps say "As of X 
date, a CA MUST NOT sign a non-technically constrained certificate where 
cA=True for keys that are hosted external to the CA's infrastructure or that 
are not operated in accordance with the issuing CA's policies and procedures 
unless Mozilla has first granted permission for such certificate"? The wording 
needs work of course, but the idea is that they go through the discussion and 
Mozilla signs off. A process for unconstrained Sub CAs that is substantially 
similar to the root inclusion makes sense, but there is documentation on CCADB 
for the existing ones

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

[Jeremy Rowley via dev-security-policy]

Will this permit either verification of the email address or the domain part? 
For example, some organizations may verify their entire domain space and then 
confirm contractors using a random value sent to the email address itself. They 
don't  need the entire domain space in those cases, but they do need to issue 
certificates for a few email addresses outside of their domain control. 
Verification of email control using a random value seems like it affords 
controls that are equivalent to the challenge-response mechanisms in the BRs.  

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Friday, October 4, 2019 2:38 PM
To: Kathleen Wilson 
Cc: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for 
S/MIME Certificates

I'd like to revive this discussion. So far we've established that the existing 
"required practice" [1] is too stringent for email address validation and needs 
to be changed. We can do that by removing email addresses from the scope of the 
requirement as Kathleen proposed, or by exempting the local part of the email 
address as I proposed earlier:

"CAs MUST NOT delegate validation of the domain name part of an email address 
to a 3rd party."

We have a fairly detailed explanation from Ryan Hurst of why and how removing 
the requirement entirely is beneficial, but no one else has spoken in favor of 
this need. Kathleen did however point out that this requirement doesn't appear 
to be the result of a thorough analysis. We have Ryan Sleevi arguing that the 
process described by Ryan Hurst is insecure and thus a reason to forbid 
delegation of validation of the domain name part. Pedro Fuentes also wrote in 
favor of this outcome.

One thing that might help to resolve this is a more detailed description of the 
weaknesses that are present in the process described by Ryan Hurst. If we can 
all agree that the process is vulnerable, then it seems that we'd have a strong 
argument for banning it.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties


On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > The BRs forbid delegation of domain and IP address validation to 
> > third parties. However, the BRs don't forbid delegation of email 
> > address validation nor do they apply to S/MIME certificates.
> >
> > Delegation of email address validation is already addressed by 
> > Mozilla's Forbidden Practices [1] state:
> >
> > "Domain and Email validation are core requirements of the Mozilla's 
> > Root Store Policy and should always be incorporated into the issuing 
> > CA's procedures. Delegating this function to 3rd parties is not permitted."
> >
> > I propose that we move this statement (changing "the Mozilla's Root 
> > Store Policy" to "this policy") into policy section 2.2 "Validation 
> > Practices".
> >
> > This is https://github.com/mozilla/pkipolicy/issues/175
> >
> > I will appreciate everyone's input on this proposal.
> >
> > - Wayne
> >
> > [1]
> >
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegat
> ion_of_Domain_.2F_Email_Validation_to_Third_Parties
> >
>
>
> All,
>
> As the person who filed the Github issue for this, I would like to 
> provide some background and my opinion.
>
> Currently the 'Delegation of Domain / Email Validation to Third Parties'
> section of the 'Forbidden Practices' page says:
> "This is forbidden by the Baseline Requirements, section 1.3.2.
> Domain and Email validation are core requirements of the Mozilla's 
> Root Store Policy and should always be incorporated into the issuing 
> CA's procedures. Delegating this function to 3rd parties is not permitted."
>
> Based on the way that section is written, it appears that domain 
> validation (and the BRs) was the primary consideration, and that the 
> Email part of it was an afterthought, or added later. Historically, my 
> attention has been focused on TLS certs, so it is possible that the 
> ramifications of adding Email validation to this section was not fully 
> thought through.
>
> I don't remember who added this email validation text or when, but I 
> can tell you that when I review root inclusion requests I have only 
> been concerned about making sure that domain validation is not being 
> delegated to 3rd parties. It wasn't until a representative of a CA 
> brought this to my attention that I realized that there has been a 
> difference in text on this wiki page versus the rules I have been 
> trying to enforce. That is when I filed the github issue.
>
> I propose that we can resolve this discrepancy for now by removing "/ 
> Email Validation" from the title of the section and removing "and Email"
> from the contents of the section.
>
> Unless we believe there are significant sec

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

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

Policy 2.7 Proposal: Update Appeal Process

[Wayne Thayer via dev-security-policy]

The last sentence of section 1.2 Policy Ownership states:

CAs or others objecting to a particular decision by either team MAY appeal
> to the Mozilla governance module owner
>  who will make a
> final decision.
>

Last year [1], Mozilla delegated this responsibility to the Firefox
Technical Leadership Module [2], and I have updated this sentence to
reflect that change [3].

This is https://github.com/mozilla/pkipolicy/issues/191

I will plan to make this change unless objections are raised.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.governance/YTTqUzWaJ00/-MopTK71AwAJ
[2] https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership
[3]
https://github.com/mozilla/pkipolicy/commit/2a30327cde67e9431cb9d6b5c270d7ad855887bd
___
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 Fri, Oct 4, 2019 at 4:37 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> One thing that might help to resolve this is a more detailed description of
> the weaknesses that are present in the process described by Ryan Hurst. If
> we can all agree that the process is vulnerable, then it seems that we'd
> have a strong argument for banning it.


The issue is that Ryan Hurst hasn't really described a reliable, verifiable
way to have assurance that the RA actually performs this verification. It's
functionally akin to the "any other method", without any meaningful
supervision. This is the same issue that Gerv had with delegated third
parties performing the domain validation.

Ryan's described algorithm basically means that any service you click "sign
in to Google" (i.e. OAuth) with could potentially obtain an S/MIME
certificate for you, on your behalf, without any authorization or
interaction with the CA by you the user, or by GMail as the domain holder.
That's quite literally the design captured in the diagram (
https://www.dropbox.com/s/ocfow995aluowyl/auth%20redirect%20cert%20flow.png?dl=0
),
at least from the perspective of an external party.

However, on a technical level, it's even worse. It relies on pinky swears
(aka contracts) between the RA and the CA. The RA is quite literally
allowed to request certificates for any domain and user, but pinky-swears
to the CA that it will only request certificates for users who click "sign
in with Google", and (hopefully, but not specified) if they agree to that.
In this scenario, the operator of the domain name (e.g. "gmail.com") has no
control over this - not even CAA. The end-user has no awareness of this
issuance either - any OAuth login could be used to cause issuance of an
S/MIME certificate.

The "benefit" of this scenario is that it just works with OAuth, and the
user never has to know which CA is dealing certs out in their name. They
may never even see the cert - the RA (service provider) may be the only one
with the keys, acting in the user's name, simply because they signed in.

All of this is under the /best/ case scenario. You could just forgo the
OAuth dance entirely - the RA could just tell the CA "Yo, give me a cert
for that Sleevi guy", and that would be that.

This is why I think it's crucial to require the CA perform the domain
validation portion. It requires that, in this case, the email provider
authorize the CA (if the CA is going to have a blank check for that
domain), or that the user authorize the CA (if the CA is only going to be
able to issue for that user). This does make it hard to just issue certs to
whomever you want. That's a feature, not a bug, and would be key to any
future improvements we might want to see in this space (e.g. CAA)

Is there a path with OAuth to allow delegation? Well, yes, there's a whole
host of concepts in signed assertions and JWT where you might allow Service
Provider to obtain a signed assertion from Mail Provider to act on behalf
of the user, and that Service Provider could in turn hand that signed
assertion to any CA, and the CA could verify that assertion back with Mail
Provider that the Service Provider was authorized. But that's not what is
described in the diagram, because that requires changes to Mail Provider,
and the 'desired benefit' of omitting this requirement from policy is to
allow issuing arbitrary certificates without the explicit, quantifiable
consent of the user or the mail provider. I think that's insecure.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/3/2019 8:44 PM, Matt Palmer via dev-security-policy wrote:

On Thu, Oct 03, 2019 at 05:36:50PM -0700, Ronald Crane via dev-security-policy 
wrote:

On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote:

[snip]

I guess I wasn't specific enough. I am looking for a good study that
supports the proposition that the Internet community has (1) made a
concerted effort to ensure that there is only one authentic domain per
entity (or, at most, per entity-service, e.g, retail brokerage
services); and (2) has made a concerted effort to educate users to use
only that domain; and (3) that those steps have failed to significantly
reduce the successful phishing rate of the users that steps (1) and (2)
targeted.


Was it intentional to presume that (1) is correct or desirable? It’s
unclear if you believe it is, but if it isn’t (and for many reasons, it
isn’t), then naturally one might assume (2) and (3) don’t exist.

Yes, I do believe that (1) is desirable. It has a long history in the
context of brand identity (e.g., "Coke" in red and white script), where
virtually all consumers use it to identify authentic products and reject
counterfeits.

This is a valuable analogy, but I'm not sure how it advances the argument
you appear to be making.

To take the specific example you've provided, there is more than one product
made under the general brand of "Coke", most -- but not all -- involving the
word "Coke" in way or another.  If we take the "domain name per product"
analogy, there would be a bunch of different "domains" for these products:
coke, newcoke, cocacolaclassic, dietcoke, cokezero, vanillacoke,
caffeinefreecoke, and so on.

That's before we start considering other products produced and marketed by
the same company under different names.  There's a bunch of other carbonated
beverages, plus uncarbonated beverages, and even non-beverage foodstuffs,
that are all produced and/or marketed by the company that produces and
markets "Coke", at least in the country I'm from.


This is something of a nit, but my proposal is more along the lines of 
"one domain per entity, or per entity-service", so in this case there 
would be perhaps the single domain "cokedrinks.com", and paths or 
subdomains for Coke Classic, New Coke, etc. Or, even better, the single 
domain "coke.com" whose paths and/or subdomains house Coca-Cola's entire 
product web presence.



...
Where the analogy breaks down is that in the case of phishing, people don't
typically try to "counterfeit" the domain name, merely "confuse"...

Agree.

Basically, many internet-based entities appear to have brought phishing upon
themselves by failing to extend the above to their internet presences.
Instead, they've trained their users to accept as authentic any domain that
has a passing resemblance to their rat's-nest of legitimate domains.

While there's a certain amount of truth to that, I think quite a lot of it
is users just not checking *anything* about the link they're clicking.  The
amount of spam I get inviting me to login to various banking websites using
a link to yevgeniysflowershoppe.ua or the like would suggest that phishing
doesn't not absolutely rely on confusion.  Your hypothesis relies on the
idea that users can be trained in any meaningful fashion, which the research
seems to not support at all.


Hmm. The idea that users are untrainable seems so foreign to me. One 
reason is that, as I noted above, so many internet entities have been 
training users to do the *wrong* things. It's not just rat's-nests of 
legitimate domains. It's also non-ASCII-128 characters, thousand of 
gTLDs, JS on-click handlers that make the link destination in the 
browser's status bar unreliable, the app culture (e.g., install Joe's 
Gas Station app today and get discounts!), and, unfortunately, even the 
nature of hypertext itself (click, click, click, BOOM!). It's registrars 
registering obvious phishing domains (are there no BRs for registrars?). 
It's users running everything as root, mostly because they don't know 
better. It's security bugs (ugh! I've reported  >200 of these over the 
past few years). It's caller-ID impersonation. It's


To switch topics a bit, I am wondering whether a foundation-run 
whitelist might help cut confusion-related phishing. This is not fleshed 
out, but the basic idea that the user's browser tests domains against a 
whitelist of domains that are known to be authentic. The foundation 
running this project should prefill the whitelist with all 
known-authentic domains. It should identify probable-phishing domains 
(e.g., pretty much anything containing a string like "paypal" or 
"facebook") and omit them from the whitelist unless it obtains 
permission to include them from the appropriate administrative contact 
for the authentic domain(s) that they're suspected of phishing. Domains 
that do not appear to be phishing domains, and that don't appear in 
major blacklists (e.g, GSB), should be added to the whitelist.


When the us

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

[Wayne Thayer via dev-security-policy]

I'd like to revive this discussion. So far we've established that the
existing "required practice" [1] is too stringent for email address
validation and needs to be changed. We can do that by removing email
addresses from the scope of the requirement as Kathleen proposed, or by
exempting the local part of the email address as I proposed earlier:

"CAs MUST NOT delegate validation of the domain name part of an email
address to a 3rd party."

We have a fairly detailed explanation from Ryan Hurst of why and how
removing the requirement entirely is beneficial, but no one else has spoken
in favor of this need. Kathleen did however point out that this requirement
doesn't appear to be the result of a thorough analysis. We have Ryan Sleevi
arguing that the process described by Ryan Hurst is insecure and thus a
reason to forbid delegation of validation of the domain name part. Pedro
Fuentes also wrote in favor of this outcome.

One thing that might help to resolve this is a more detailed description of
the weaknesses that are present in the process described by Ryan Hurst. If
we can all agree that the process is vulnerable, then it seems that we'd
have a strong argument for banning it.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties


On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > The BRs forbid delegation of domain and IP address validation to third
> > parties. However, the BRs don't forbid delegation of email address
> > validation nor do they apply to S/MIME certificates.
> >
> > Delegation of email address validation is already addressed by Mozilla's
> > Forbidden Practices [1] state:
> >
> > "Domain and Email validation are core requirements of the Mozilla's Root
> > Store Policy and should always be incorporated into the issuing CA's
> > procedures. Delegating this function to 3rd parties is not permitted."
> >
> > I propose that we move this statement (changing "the Mozilla's Root Store
> > Policy" to "this policy") into policy section 2.2 "Validation Practices".
> >
> > This is https://github.com/mozilla/pkipolicy/issues/175
> >
> > I will appreciate everyone's input on this proposal.
> >
> > - Wayne
> >
> > [1]
> >
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
> >
>
>
> All,
>
> As the person who filed the Github issue for this, I would like to
> provide some background and my opinion.
>
> Currently the 'Delegation of Domain / Email Validation to Third Parties'
> section of the 'Forbidden Practices' page says:
> "This is forbidden by the Baseline Requirements, section 1.3.2.
> Domain and Email validation are core requirements of the Mozilla's Root
> Store Policy and should always be incorporated into the issuing CA's
> procedures. Delegating this function to 3rd parties is not permitted."
>
> Based on the way that section is written, it appears that domain
> validation (and the BRs) was the primary consideration, and that the
> Email part of it was an afterthought, or added later. Historically, my
> attention has been focused on TLS certs, so it is possible that the
> ramifications of adding Email validation to this section was not fully
> thought through.
>
> I don't remember who added this email validation text or when, but I can
> tell you that when I review root inclusion requests I have only been
> concerned about making sure that domain validation is not being
> delegated to 3rd parties. It wasn't until a representative of a CA
> brought this to my attention that I realized that there has been a
> difference in text on this wiki page versus the rules I have been trying
> to enforce. That is when I filed the github issue.
>
> I propose that we can resolve this discrepancy for now by removing "/
> Email Validation" from the title of the section and removing "and Email"
> from the contents of the section.
>
> Unless we believe there are significant security reasons to add our own
> S/MIME required/forbidden practices at this time, my preference is to
> wait for the CA/Browser Forum to create the S/MIME Working Group, and
> for that group to identify the S/MIME baseline requirements. Then we can
> add policy and required/forbidden practices based on the S/MIME BRs
> provided by that group.
>
> I do realize that my proposal is unfair to CAs who have been diligently
> following this section of this wiki page. Your diligence is appreciated,
> and your contributions to this discussion will also be appreciated.
>
> Thanks,
> 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

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Wayne Thayer via dev-security-policy]

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 idea on the number that might entail? At worst, we waste a bunch of
> time discovering that all of these are perfectly operated and that they
> could have been grandfathered in the first place. At best, we identify some
> critical issues and resolve them as a community.
>
>
It appears to be at least 2 dozen organizations, based on the "subordinate
CA owner" field in CCADB. I say "at least" because, as Dimitris noted,
we're just now identifying intermediates that are incorrectly labeled as
falling under the parent certificate's audits.

If there are a significant number of unconstrained on-prem CAs, then
> language that requires a review on re-signing would be helpful.  Perhaps
> say "As of X date, a CA MUST NOT sign a non-technically constrained
> certificate where cA=True for keys that are hosted external to the CA's
> infrastructure or that are not operated in accordance with the issuing CA's
> policies and procedures unless Mozilla has first granted permission for
> such certificate"? The wording needs work of course, but the idea is that
> they go through the discussion and Mozilla signs off. A process for
> unconstrained Sub CAs that is substantially similar to the root inclusion
> makes sense, but there is documentation on CCADB for the existing ones.
> Still, this documentation should probably made available, along with the
> previous incident reports, to the community for review and discussion.
> Afterall, anything not fully constrained is essentially operating the same
> as a fully embedded root.
>
>
Grandfathering in organizations currently in control of an unconstrained
subordinate CA, but requiring them to go through an approval process before
obtaining a new subordinate CA certificate seems like a good approach. I do
however have concerns about requiring a process similar to the root
inclusion process. We expect the root CA to take responsibility for the
organizations they certify, so a lighter process that acts as a
verification of the decision made by the root CA is appropriate here. To
put it another way, applying the full root inclusion process to externally
operated unconstrained subordinate CA certificates is not much different
than forbidding them. I do agree that policy docs and audits should be made
available as part of this review.

Speaking on a personal, non-DigiCert note, I think on-prem sub CAs are a
> bad idea, and I fully support more careful scrutiny on which entities are
> controlling keys. Looking at the DigiCert metrics, the on-prem Sub CAs are
> responsible for over half of the incident reports, with issues ranging from
> missed audit dates to incorrect profile information. The long cycle in
> getting information,  being a middle-man information gathering, and trying
> to convey both Mozilla and CAB forum policy makes controlling compliance
> very difficult, and a pract

RE: OCSP responder support for SHA256 issuer identifier info

[Jeremy Rowley via dev-security-policy]

(And, for the record, none of that legacy infrastructure that would Ryan 
mentions taking years to update exists anymore. Yay for shutting down legacy 
systems!)

-Original Message-
From: dev-security-policy  On 
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Friday, October 4, 2019 12:35 PM
To: Tomas Gustavsson ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: OCSP responder support for SHA256 issuer identifier info

The CAB forum specifies that OCSP responses MUST conform to RFC5019 or RFC 
6960.  The requirements do not specific which RFC to follow when processing 
requests, but I think you can imply that either one is required, right?  

Section 2.1.1. specifies that:  
Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash 
and the CertID.issuerKeyHash values. Anyone implementing the BRs would expect 
SHA1 for both fields. Where does the requirement to support SHA256 come in? As 
Ryan mentioned, there was some discussion, but it seems like there was nothing 
settled. I'd support a ballot clarifying the profile, but I don't understand 
the value of requiring both SHA1 and SHA2 signatures for OCSP. Doesn't it just 
make OCSP more cumbersome? 

-Original Message-
From: dev-security-policy  On 
Behalf Of Tomas Gustavsson via dev-security-policy
Sent: Friday, October 4, 2019 1:45 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: OCSP responder support for SHA256 issuer identifier info

I was pointed to this interesting discussion. We were forced to support 
requests with SHA256 in CertID back in 2014. Not for any relevant security 
reasons, just because some stubborn auditors saw a red flag on the mentioning 
of SHA-1.

We've implemented it by having both hashes in the lookup table where we check 
for issuer when a response comes in. 

What to have in the response was an interesting topic.

In the response we use the same certID that the client sent. I would expect 
that any client if checking CertID in the response would expect it to match 
what they send. 

I'm suspicious of adding two SingleResponse in the response, one for each 
CertID. 
- Clients are used to one response, they may fail verification if the first one 
doesn't have the same CertID
- When auditors that requiring SHA3, shall we add three? That approach does not 
seem agile.
- It increases the size of responses, we've been told before about the desire 
to keep responses as small as possible (typically to fit in a single etehrnet 
frame)

Regards,
Tomas

On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote:
> Thanks for raising this!
> 
> There some some slight past discussion in the CA/B Forum on this - 
> https://cabforum.org/pipermail/public/2013-November/002440.html - as 
> well as a little during the SHA-1 deprecation discussions ( 
> https://cabforum.org/pipermail/public/2016-November/008979.html ) and 
> crypto agility discussions ( 
> https://cabforum.org/pipermail/public/2014-September/003921.html ), 
> but none really nailed it down to the level you have.
> 
> Broadly, it suggests the need for a much tighter profile of OCSP, 
> either within policies or the BRs. Two years ago, I started work on 
> such a thing -
> https://github.com/sleevi/cabforum-docs/pull/2 - but a certain large 
> CA suggested it would take them years to even implement that, and it 
> wouldn't have covered this!
> 
> I can't see #3 being valid, but I can see and understand good 
> arguments for
> #1 and #4. I don't think #5 works, because of Section 2.3 of RFC 6960.
> 
> The question about whether #2 is valid is about whether or not a 
> client should be expected to be able to match the CertID in the 
> OCSPRequest.requestList to the CertID in the 
> OCSPResponse.BasicOCSPResponse.responses list. 4.2.2.3 requires that 
> the response MUST include a SingleResponse for each certificate in the 
> request, but may include additional, and so a client encountering a
> SHA-1 computed CertID in response to a SHA-256 CertID would have to 
> recompute all the CertIDs to see if it matched. On the other hand, RFC
> 5019 2.2.1 states that "In the case where a responder does not have 
> the ability to respond to an OCSP response containing an option not 
> supported by the server, it SHOULD return the most complete response it can."
> 
> A different question would be whether said responder, in response to a
> SHA-1 request, can and/or should provide a response with both a SHA-1 
> computed CertID AND a SHA-256 computed CertID. This would improve the 
> pre-generation performance that Rob was concerned about, and allow 
> both
> SHA-1 and SHA-2 requests to be satisfied by the same BasicOCSPResponse.
> 
> However, one concern with the pre-generation approach is that 4.2.2.3 
> requires that the response MUST include a SingleResponse for each 
> certificate in the request. RFC 5019 2.1.1 limits clients using that 
> profile to only include one Request in the OCSPRequest.RequestList 
> (vi

RE: OCSP responder support for SHA256 issuer identifier info

[Jeremy Rowley via dev-security-policy]

The CAB forum specifies that OCSP responses MUST conform to RFC5019 or RFC 
6960.  The requirements do not specific which RFC to follow when processing 
requests, but I think you can imply that either one is required, right?  

Section 2.1.1. specifies that:  
Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash 
and the CertID.issuerKeyHash values. Anyone implementing the BRs would expect 
SHA1 for both fields. Where does the requirement to support SHA256 come in? As 
Ryan mentioned, there was some discussion, but it seems like there was nothing 
settled. I'd support a ballot clarifying the profile, but I don't understand 
the value of requiring both SHA1 and SHA2 signatures for OCSP. Doesn't it just 
make OCSP more cumbersome? 

-Original Message-
From: dev-security-policy  On 
Behalf Of Tomas Gustavsson via dev-security-policy
Sent: Friday, October 4, 2019 1:45 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: OCSP responder support for SHA256 issuer identifier info

I was pointed to this interesting discussion. We were forced to support 
requests with SHA256 in CertID back in 2014. Not for any relevant security 
reasons, just because some stubborn auditors saw a red flag on the mentioning 
of SHA-1.

We've implemented it by having both hashes in the lookup table where we check 
for issuer when a response comes in. 

What to have in the response was an interesting topic.

In the response we use the same certID that the client sent. I would expect 
that any client if checking CertID in the response would expect it to match 
what they send. 

I'm suspicious of adding two SingleResponse in the response, one for each 
CertID. 
- Clients are used to one response, they may fail verification if the first one 
doesn't have the same CertID
- When auditors that requiring SHA3, shall we add three? That approach does not 
seem agile.
- It increases the size of responses, we've been told before about the desire 
to keep responses as small as possible (typically to fit in a single etehrnet 
frame)

Regards,
Tomas

On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote:
> Thanks for raising this!
> 
> There some some slight past discussion in the CA/B Forum on this - 
> https://cabforum.org/pipermail/public/2013-November/002440.html - as 
> well as a little during the SHA-1 deprecation discussions ( 
> https://cabforum.org/pipermail/public/2016-November/008979.html ) and 
> crypto agility discussions ( 
> https://cabforum.org/pipermail/public/2014-September/003921.html ), 
> but none really nailed it down to the level you have.
> 
> Broadly, it suggests the need for a much tighter profile of OCSP, 
> either within policies or the BRs. Two years ago, I started work on 
> such a thing -
> https://github.com/sleevi/cabforum-docs/pull/2 - but a certain large 
> CA suggested it would take them years to even implement that, and it 
> wouldn't have covered this!
> 
> I can't see #3 being valid, but I can see and understand good 
> arguments for
> #1 and #4. I don't think #5 works, because of Section 2.3 of RFC 6960.
> 
> The question about whether #2 is valid is about whether or not a 
> client should be expected to be able to match the CertID in the 
> OCSPRequest.requestList to the CertID in the 
> OCSPResponse.BasicOCSPResponse.responses list. 4.2.2.3 requires that 
> the response MUST include a SingleResponse for each certificate in the 
> request, but may include additional, and so a client encountering a 
> SHA-1 computed CertID in response to a SHA-256 CertID would have to 
> recompute all the CertIDs to see if it matched. On the other hand, RFC 
> 5019 2.2.1 states that "In the case where a responder does not have 
> the ability to respond to an OCSP response containing an option not 
> supported by the server, it SHOULD return the most complete response it can."
> 
> A different question would be whether said responder, in response to a
> SHA-1 request, can and/or should provide a response with both a SHA-1 
> computed CertID AND a SHA-256 computed CertID. This would improve the 
> pre-generation performance that Rob was concerned about, and allow 
> both
> SHA-1 and SHA-2 requests to be satisfied by the same BasicOCSPResponse.
> 
> However, one concern with the pre-generation approach is that 4.2.2.3 
> requires that the response MUST include a SingleResponse for each 
> certificate in the request. RFC 5019 2.1.1 limits clients using that 
> profile to only include one Request in the OCSPRequest.RequestList 
> (via a MUST). So should responders be permitted to reject requests 
> that include multiple? Or should they be required to do online 
> signing? Similar to extensions.
> 
> This suggests we should actually nail down and define what we expect, 
> perhaps as a clear processing algorithm for how a Responder must 
> respond to various requests. I suspect that "What we want" is a 
> profile of RFC 5019 that nails down the SHOULD / SHOULD NOT and MAY /

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Dimitris Zacharopoulos via dev-security-policy]

On 2019-10-04 12:56 μ.μ., Rob Stradling wrote:

Dimitris,

Since CAs should already be disclosing that an intermediate 
certificate is "externally-operated" by populating the "Subordinate CA 
Owner" field in the CCADB record, what's the benefit of duplicating 
this information in the intermediate certificate itself?


What happens if an intermediate certificate starts life as 
"externally-operated" but later becomes "internally-operated", or 
vice-versa?  (e.g., the root CA company acquires the intermediate CA 
company).


It's possible to update a CCADB record.  It's not possible to update a 
certificate.




That makes sense. This means that Mozilla has a way to know exactly how 
many externally-operated CAs are in the Root program, provided all CAs 
updated this "Subordinate CA Owner" field correctly, meaning that the 
"Subordinate CA Owner" operates/manages the CA keys.


Dimitris.



*From:* dev-security-policy 
 on behalf of Dimitris 
Zacharopoulos via dev-security-policy 


*Sent:* 04 October 2019 05:43
*To:* mozilla-dev-security-policy 

*Subject:* Re: Policy 2.7 Proposal:Extend Section 8 to Encompass 
Subordinate CAs

Adding to Jeremy's post, I believe we need to also define a normative
requirement to mark an unconstrained Intermediate CA Certificate not
operated by the entity that controls the Root Key.
Section 7.1.6.3 of the Baseline Requirements requires an explicit policy
identifier for these subCAs. The anyPolicy identifier is not permitted.
So, I assume that all Intermediate CA Certificates that include the
anyPolicy identifier should be operated by the Issuing CA (or an 
Affiliate).


Unfortunately -in one sense-, the BRs allow more specific policy
identifiers even for Intermediate CA Certificates that ARE operated by
the Issuing CA, so it is hard to differentiate which subCA is "Internal"
or "External".

I believe this is serious enough to consider the possibility of
requiring a specific policy identifier (assigned by the CABF) to be
included in externally-operated subCA Certificates, in addition to any
other policy identifiers that the Issuing CA has chosen for that CA
Certificate. Of course, other solutions might be available.

Mozilla is also going over a close investigation of unconstrained subCAs
that are missing audits and possibly included in oneCRL. I don't believe
these subCAs should be grandfathered in. However, others that have
supplied audit reports, following Mozilla Policies and indicating
compliance with the BRs, should be grandfathered.


Dimitris.



On 2019-10-04 3:06 π.μ., Jeremy Rowley via dev-security-policy 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.

>
> 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. 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 idea on the number that might entail
>   ? At worst, we waste a bunch of time discovering that all of these 
are perfectly operated and that they could have been grandfathered in 
the first place. At best, we identify some critical issues and resolve 
them as a community.

>
> If there are a significant number of unconstrained on-prem CAs, then 
language that requires a review on re-signing would be helpful.  
Perhaps say "As of X date, a CA MUST NOT sign a non-technically 
constrained certificate where cA=True for keys that are hosted 
external to the CA's infrastructure or that are not operated in 
accordanc

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Rob Stradling via dev-security-policy]

Dimitris,

Since CAs should already be disclosing that an intermediate certificate is 
"externally-operated" by populating the "Subordinate CA Owner" field in the 
CCADB record, what's the benefit of duplicating this information in the 
intermediate certificate itself?

What happens if an intermediate certificate starts life as 
"externally-operated" but later becomes "internally-operated", or vice-versa?  
(e.g., the root CA company acquires the intermediate CA company).

It's possible to update a CCADB record.  It's not possible to update a 
certificate.


From: dev-security-policy  on 
behalf of Dimitris Zacharopoulos via dev-security-policy 

Sent: 04 October 2019 05:43
To: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

Adding to Jeremy's post, I believe we need to also define a normative
requirement to mark an unconstrained Intermediate CA Certificate not
operated by the entity that controls the Root Key.
Section 7.1.6.3 of the Baseline Requirements requires an explicit policy
identifier for these subCAs. The anyPolicy identifier is not permitted.
So, I assume that all Intermediate CA Certificates that include the
anyPolicy identifier should be operated by the Issuing CA (or an Affiliate).

Unfortunately -in one sense-, the BRs allow more specific policy
identifiers even for Intermediate CA Certificates that ARE operated by
the Issuing CA, so it is hard to differentiate which subCA is "Internal"
or "External".

I believe this is serious enough to consider the possibility of
requiring a specific policy identifier (assigned by the CABF) to be
included in externally-operated subCA Certificates, in addition to any
other policy identifiers that the Issuing CA has chosen for that CA
Certificate. Of course, other solutions might be available.

Mozilla is also going over a close investigation of unconstrained subCAs
that are missing audits and possibly included in oneCRL. I don't believe
these subCAs should be grandfathered in. However, others that have
supplied audit reports, following Mozilla Policies and indicating
compliance with the BRs, should be grandfathered.


Dimitris.



On 2019-10-04 3:06 π.μ., Jeremy Rowley via dev-security-policy 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.
>
> 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. 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 idea on the number that might entail
>   ? At worst, we waste a bunch of time discovering that all of these are 
> perfectly operated and that they could have been grandfathered in the first 
> place. At best, we identify some critical issues and resolve them as a 
> community.
>
> If there are a significant number of unconstrained on-prem CAs, then language 
> that requires a review on re-signing would be helpful.  Perhaps say "As of X 
> date, a CA MUST NOT sign a non-technically constrained certificate where 
> cA=True for keys that are hosted external to the CA's infrastructure or that 
> are not operated in accordance with the issuing CA's policies and procedures 
> unless Mozilla has first granted permission for such certificate"? The 
> wording needs work of course, but the idea is that they go through the 
> discussion and Mozilla signs off. A process for unconstrained Sub CAs that is 
> substantially similar to the root inclusion makes sense, but 

Re: OCSP responder support for SHA256 issuer identifier info

[Tomas Gustavsson via dev-security-policy]

I was pointed to this interesting discussion. We were forced to support 
requests with SHA256 in CertID back in 2014. Not for any relevant security 
reasons, just because some stubborn auditors saw a red flag on the mentioning 
of SHA-1.

We've implemented it by having both hashes in the lookup table where we check 
for issuer when a response comes in. 

What to have in the response was an interesting topic.

In the response we use the same certID that the client sent. I would expect 
that any client if checking CertID in the response would expect it to match 
what they send. 

I'm suspicious of adding two SingleResponse in the response, one for each 
CertID. 
- Clients are used to one response, they may fail verification if the first one 
doesn't have the same CertID
- When auditors that requiring SHA3, shall we add three? That approach does not 
seem agile.
- It increases the size of responses, we've been told before about the desire 
to keep responses as small as possible (typically to fit in a single etehrnet 
frame)

Regards,
Tomas

On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote:
> Thanks for raising this!
> 
> There some some slight past discussion in the CA/B Forum on this -
> https://cabforum.org/pipermail/public/2013-November/002440.html - as well
> as a little during the SHA-1 deprecation discussions (
> https://cabforum.org/pipermail/public/2016-November/008979.html ) and
> crypto agility discussions (
> https://cabforum.org/pipermail/public/2014-September/003921.html ), but
> none really nailed it down to the level you have.
> 
> Broadly, it suggests the need for a much tighter profile of OCSP, either
> within policies or the BRs. Two years ago, I started work on such a thing -
> https://github.com/sleevi/cabforum-docs/pull/2 - but a certain large CA
> suggested it would take them years to even implement that, and it wouldn't
> have covered this!
> 
> I can't see #3 being valid, but I can see and understand good arguments for
> #1 and #4. I don't think #5 works, because of Section 2.3 of RFC 6960.
> 
> The question about whether #2 is valid is about whether or not a client
> should be expected to be able to match the CertID in the
> OCSPRequest.requestList to the CertID in the
> OCSPResponse.BasicOCSPResponse.responses list. 4.2.2.3 requires that the
> response MUST include a SingleResponse for each certificate in the request,
> but may include additional, and so a client encountering a SHA-1 computed
> CertID in response to a SHA-256 CertID would have to recompute all the
> CertIDs to see if it matched. On the other hand, RFC 5019 2.2.1 states that
> "In the case where a responder does not have the ability to respond to an
> OCSP response containing an option not supported by the server, it SHOULD
> return the most complete response it can."
> 
> A different question would be whether said responder, in response to a
> SHA-1 request, can and/or should provide a response with both a SHA-1
> computed CertID AND a SHA-256 computed CertID. This would improve the
> pre-generation performance that Rob was concerned about, and allow both
> SHA-1 and SHA-2 requests to be satisfied by the same BasicOCSPResponse.
> 
> However, one concern with the pre-generation approach is that 4.2.2.3
> requires that the response MUST include a SingleResponse for each
> certificate in the request. RFC 5019 2.1.1 limits clients using that
> profile to only include one Request in the OCSPRequest.RequestList (via a
> MUST). So should responders be permitted to reject requests that include
> multiple? Or should they be required to do online signing? Similar to
> extensions.
> 
> This suggests we should actually nail down and define what we expect,
> perhaps as a clear processing algorithm for how a Responder must respond to
> various requests. I suspect that "What we want" is a profile of RFC 5019
> that nails down the SHOULD / SHOULD NOT and MAY / MAY NOT behaviours from
> 5019, as relevant to the Web PKI, and describe a processing algorithm that
> can be used to both assess compliance and test implementation.

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