Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Bruce via dev-security-policy]

On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com wrote:
> Thanks, Bruce, for raising the issue of pre-generated, yet unassigned keys. 
> The intent was to cover this scenario. We are aware that CAs might 
> generate 1000s of keys in a partition and then years later assign a few of 
> them as CA keys, others as OCSP responder keys, etc., and some might never 
> be used. Presumably each of the keys would have an identifier and the CA 
> operator would maintain a list of those key identifiers for each partition. 
> The goal is to have an audited chain of custody for the keys, which could 
> also be based on the physical and logical protection of the HSM that is 
> holding them. 
> Key lifecycle documentation would consist of a documented key generation 
> ceremony (where such documentation is reviewed by an auditor). Then, 
> annually an auditor would review storage and access records for the HSM(s) 
> and the list of keys to see which ones had been used for CAs and which ones 
> had not. Then, as keys were destroyed (or if not, when the HSM is zeroized 
> at the end of the HSM's lifecycle), there would be an attestation of key 
> destruction that would be covered by an audit/auditor's statement.
> On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 

One more question for clarification as I want to make sure we understand how to 
get our practices updated to meet the Mozilla Policy. The requirement states 
"until the CA certificate is no longer trusted by Mozilla's root store." Can we 
confirm that a CA certificate is no longer trusted by the Mozilla root store if 
1) it has expired or 2) it has been revoked and the OneCRL has been updated. Of 
course Mozilla may have other ways to no longer trust a CA certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Bruce via dev-security-policy]

On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com wrote:
> I haven't seen any response to my question about whether there is still a 
> concern over the language "as evidenced by a Qualified Auditor's key 
> destruction report". 
> I did add "This cradle-to-grave audit requirement applies equally to 
> subordinate CAs as it does to root CAs" to address the scenarios that were 
> raised. 
> So I am going to assume that this issue is resolved and that we can move 
> this proposed change forward. 
> See 
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c8bdb949020634b1f8fa31bc060229c600fe6f9d

Ben, sorry for the late input.

We are onboard with the cradle-to-grave audit as we have experience auditing 
non-functioning CAs before they go into production and after they have stopped 
issuing certificates. However, I think there might be an issue in the 
requirement with the start and stop time of cradle-to-grave. 

At the beginning, I think that CAs will generate one or many keys, but will not 
assign them to CAs. The gap period could be days to years. Since the 
requirement says "from the time of CA key pair generation", do we want an audit 
of an unassigned key? Or should the audit start once the key has been assigned 
and the CA certificate has been generated?

At the end, subordinate CA certificate(s) may be revoked or may expire. Once 
the certificate(s) are revoked or expired, is this a reasonable time to stop 
auditing the CA as trust has been removed? Of course if the certificates are 
not revoked or expired, then all copies of the keys should be destroyed to stop 
the audit. However, I think the best practice should be that certificates 
should be revoked/expired at time of key destruction.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Is issuing a certificate for a previously-reported compromised private key misissuance?

[Bruce via dev-security-policy]

On Thursday, March 19, 2020 at 2:02:39 AM UTC-4, Matt Palmer wrote:

> 1. *Are* there explicit prohibitions on issuing a certificate for a private
>key which has been previously submitted *to that CA* as compromised 
>(assuming, of course, that the prior submission was valid), and I'm just
>not good at finding said prohibitions?
> 
BR 6.1.1.3 has a weak key clause, "The CA SHALL reject a certificate request if 
the requested Public Key does not meet the requirements set forth in Sections 
6.1.5 and 6.1.6 or if it has a known weak Private Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys)."

I would think that "issuing a certificate for a private key which has been 
previously submitted *to that CA* as compromised" is not in the spirit of the 
weak key clause. It would be best if the CA would blacklist the public key to 
prevent future issuance for the compromised private key.

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

Re: Entrust Root Certification Authority - G4 Inclusion Request

[Bruce via dev-security-policy]

On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote:

> We will update section 4.2 and 9.12.3 in the next release of the CPS.

The CPS Has been updated to address the above issues, see 
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf.

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

Re: Entrust Root Certification Authority - G4 Inclusion Request

[Bruce via dev-security-policy]

On Friday, July 26, 2019 at 1:25:13 PM UTC-4, Wayne Thayer wrote:

> ==Bad==

> * The most recent BR audit report lists two additional qualifications
> related to the Network Security requirements:
> ** During the Period, there were instances of some Certificate Systems not
> undergoing a Vulnerability Scan at least every three (3) months.
> ** During the Period, there were instances where a technical control to
> restrict remote access to only those devices owned or controlled by Entrust
> did not operate effectively.

Deloitte has issued a Specified Procedures Report to address the above 
qualified items. The report has been added to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1480510.


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

Re: Entrust Root Certification Authority - G4 Inclusion Request

[Bruce via dev-security-policy]

On Friday, July 26, 2019 at 1:25:13 PM UTC-4, Wayne Thayer wrote:

> ==Meh==

> * BR section 2.2 requires section 4.2 of a CA’s CP and/or CPS to “clearly
> specify the set of Issuer Domain Names that the CA recognises in CAA
> "issue" or "issuewild" records as permitting it to issue.” The Entrust CPS
> instead references section 3.2.2.8 where the Issuer Domain Name is listed.
> * CPS section 9.12.3 is blank. Mozilla recommends against this [11].

We will update section 4.2 and 9.12.3 in the next release of the CPS.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Entrust Root Certification Authority - G4 Inclusion Request

[Bruce via dev-security-policy]

On Friday, July 26, 2019 at 1:45:06 PM UTC-4, Ryan Sleevi wrote:
> (In a personal capacity, as normally noted but making sure to extra-note it
> here)
> 
> Hi Wayne,
> 
> It wasn't clear to me from the inclusion request, did Entrust give a reason
> for the requested addition? For example, do they plan to stop issuing from
> one of the included roots and have it removed?

The purpose of the inclusion request is to add a 4096-bit RSA root which will 
be used to support larger keys as we move ahead. We are not looking at this 
root to replace our current roots, but plan to migrate to the new root as the 
demand for larger keys grows. We are not planning remove any of our roots at 
this time.

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

Incident Report - Entrust Datacard issued certificates with the incorrect Organization Name

[Bruce via dev-security-policy]

On March 7, 2019, Entrust Datacard discovered that SSL certificates with the 
wrong Organization value were issued to a customer. The investigation was 
completed 15 March 2019.

Details of the incident report can be found here, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1535735. 

All certificates will be revoked by 20 March 2019.

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

Incident Report - Entrust did not revoke all certificates with underscore characters before the 15 January 2019 dealine

[Bruce via dev-security-policy]

On January 18, 2019, Entrust discovered that 9 SSL certificates with underscore 
characters which were issued for more than 30 days were not revoked before 15 
January 2019. All certificates were revoked on 18 January 2019.

Details of the incident report can be found here, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1521520.

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

Re: s/MIME certs and authentication

[Bruce via dev-security-policy]

On Wednesday, December 12, 2018 at 7:59:46 PM UTC-5, Jeremy Rowley wrote:

> Some systems look like they verify the email address/domain name at issuance
> and then never again for the same account. Other systems verify the email
> address and domain every 825 days. The last set verifies the email address
> each time a certificate is issued.  I think each are equally compliant, but
> the set-it-and-forget it method doesn't seem in the spirit of ensuring
> control over the email address. Is there guidance on how often this
> reverification should occur?

We have implemented the 825-day rule from the SSL BRs to re-verify information 
for an S/MIME certificate. This rule is applied to the information in the 
subject DN and the email address/domain. As such, we have also implemented the 
825-day reuse rule. This also allows the use of the same information for 
different certificate types.

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

Incident report - Certificate issued with '-' in ST field

[Bruce via dev-security-policy]

On November 19, 2018 an SSL certificate was issued with '-' in the ST field of 
the subject DN. The certificate has been revoked.

Details of the incident report can be found here, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1512018.

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

Re: CA Communication: Underscores in dNSNames

[Bruce via dev-security-policy]

Hi Wayne, I wanted to get some clarification.

For example, let's say that a Subscriber has a 1 year certificate which expires 
on 30 January 2019. On 15 January 2019, the remaining validity period is less 
than 30 days; as such, I interpret that the certificate does not have to be 
revoked.

On the other hand, if the Subscriber has a 1 year certificate which expires on 
31 March 2019, then on 15 January 2019, the remaining validity period is 
greater than 30 days, so this certificate must be revoked.

Is the above interpretation correct?

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

Re: DRAFT September 2018 CA Communication

[Bruce via dev-security-policy]

On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne Thayer wrote:
> All,
> 
> I've drafted a new email and survey that I hope to send to all CAs in the
> Mozilla program next week. it focuses on compliance with the new (2.6.1)
> version of our Root Store Policy. I would appreciate your feedback on the
> draft:
> 
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3rMGLL
> 
> 
> Thanks,
> 
> Wayne

With regard to the actions.

ACTION 6 - Can we select CA certificates which we do not want pre-loaded? In 
some cases the CA certificate is no longer used and does not need pre-loading.

ACTION 7 - Although we support the Chrome CT requirement, we do have a process 
to allow customers to choose not to CT log their certain SSL certificates. We 
do not redact names, but I suppose we allow a customer to redact certificates. 
As such, I don't think the responses listed in action 7 covers this model.

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

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

[Bruce via dev-security-policy]

On Monday, July 16, 2018 at 7:25:09 PM UTC-4, Wayne Thayer wrote:
> On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Yeah, I agree I don’t think it was intended.  But now that I am aware of
> > the issue, I think the crossing workaround per EKU is actually a good thing
> > for people to be doing.  Unless someone can point out why it's bad ...
> >
> >
> >
> I'd like to consider any new restrictions on cross-certificates separately.
> I've created https://github.com/mozilla/pkipolicy/issues/145 to track this
> idea, and added that if we go that far we should also think about
> restricting roots to either the Mozilla websites or email trust bit.
> 
> Might want to give people a little more time to plan and adapt to that
> > change though since I doubt anyone thought of it and people need planning
> > runway to change their procedures if it is going to be interpreted this way.
> >
> >
> >
> It seems that we have agreement that the current change was not intended to
> apply to cross certificates. I think that is the meaning of the existing
> language, but it would be clearer if the final paragraph of section 5.3 was
> amended to:
> 
> These requirements include all intermediate certificates signed by
> cross-certificates which chain to a certificate that is included in
> Mozilla’s CA Certificate Program.
> 
> Questions:
> - does anyone object to that new wording?
> - should the official policy be updated with this change prior to 1-Jan
> when the requirement to separate usages of new intermediate certificates
> goes into effect, or can this wait since it is only a clarification?

Since this is only a clarification, then  I think the change can wait until the 
next update of the Mozilla policy.

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

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

[Bruce via dev-security-policy]

Agreed that old cross-certificates will not be impacted, but this does impact 
new cross-certificates. I assume the work around would be to just issue more 
than one cross-certificate with different EKUs, but I don't assume that was 
intended by this policy change.

Bruce.

On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote:
> Doesn't the "created after January 1, 2019" mean that there is no problem 
> with old crosses?  It would just be a new policy for new crosses as of next 
> year?
> 
> -Tim
> 
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Bruce via
> > dev-security-policy
> > Sent: Thursday, July 12, 2018 10:28 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> > S/MIME?
> > 
> > Note the BRs define Cross Certificate as "a certificate that is used to 
> > establish a
> > trust relationship between two Root CAs."
> > 
> > I think the intent was to technically restrict subordinate CAs or rather CAs
> > which are online and issue end entity certificates. My assumption is that we
> > want to 1) not allow a subordinate CA to issue a certificate which it was no
> > intended to issue and 2) mitigate the risk if an online subordinate CA has 
> > been
> > compromised.
> > 
> > Typically, if an old root cross-certifies a new root, the purpose is to 
> > give the
> > new root browser/OS ubiquity. The new root may be used to support end
> > entity certificates of many types (e.g., Server Auth, S/MIME, Client Auth, 
> > Code
> > Signing, Document Signing, Time-stamping ...). If we restrict the cross-
> > certificate, then this will limit the use of a new root. Also note that the 
> > new
> > root is 1) not an issuing CA and 2) is offline, so the mitigation of 
> > technical
> > restriction may already be satisfied.
> > 
> > Thanks, Bruce.
> > 
> > On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote:
> > > During a 2.6 policy discussion [1], we agreed to add the following
> > > language to section 5.3 "Intermediate Certificates":
> > >
> > > > Intermediate certificates created after January 1, 2019:
> > > >
> > > >
> > > > * MUST contain an EKU extension; and,
> > > > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
> > > > * MUST NOT include both the id-kp-serverAuth and
> > > > id-kp-emailProtection KeyPurposeIds in the same certificate.
> > > >
> > >
> > > It has been pointed out to me that the very next paragraph of section
> > > 5.3
> > > states:
> > >
> > > These requirements include all cross-certified certificates which
> > > chain to
> > > > a certificate that is included in Mozilla’s CA Certificate Program.
> > > >
> > >
> > > The term "cross-certified certificates" could refer to the actual
> > > cross-certificate, or it could refer to intermediate certificates that
> > > chain up to the cross certificate. In the case of a root that is being
> > > cross-certified, the former interpretation effectively means that
> > > distinct cross-certificates would be required for serverAuth and
> > > emailProtection, as
> > > follows:
> > >
> > > 1 - Root <-- Cross-certificate (EKU=emailProtection) <-- Intermediate
> > > certificate (EKU=emailProtection) <-- leaf certificate (S/MIME)
> > > 2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate
> > > certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS)
> > >
> > > Should our policy require cross-certificates to be constrained to
> > > either serverAuth or emailProtection via EKU, or should this
> > > requirement only apply to [all other] intermediate certificates?
> > >
> > > What is the correct interpretation of section 5.3 of the policy as
> > > currently written?
> > >
> > > I would appreciate everyone's input on these questions.
> > >
> > > - Wayne
> > >
> > > [1]
> > >
> > https://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH
> > iAL
> > > jfsD2zgM=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy-
> > 9DLApGl29o_1WR_vWTXMDk0d9kBFu
> > >
> > rU6JcvMPF1WEp4WBRfAgKXpN15C1244hstaDLxsVmE8bwd8UMj0MNvk5w_Q
> > C8ibEWzPC_L
> &

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

[Bruce via dev-security-policy]

Note the BRs define Cross Certificate as "a certificate that is used to 
establish a trust relationship between two Root CAs."

I think the intent was to technically restrict subordinate CAs or rather CAs 
which are online and issue end entity certificates. My assumption is that we 
want to 1) not allow a subordinate CA to issue a certificate which it was no 
intended to issue and 2) mitigate the risk if an online subordinate CA has been 
compromised. 

Typically, if an old root cross-certifies a new root, the purpose is to give 
the new root browser/OS ubiquity. The new root may be used to support end 
entity certificates of many types (e.g., Server Auth, S/MIME, Client Auth, Code 
Signing, Document Signing, Time-stamping ...). If we restrict the 
cross-certificate, then this will limit the use of a new root. Also note that 
the new root is 1) not an issuing CA and 2) is offline, so the mitigation of 
technical restriction may already be satisfied.

Thanks, Bruce. 

On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote:
> During a 2.6 policy discussion [1], we agreed to add the following language
> to section 5.3 "Intermediate Certificates":
> 
> > Intermediate certificates created after January 1, 2019:
> >
> >
> > * MUST contain an EKU extension; and,
> > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
> > * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection
> > KeyPurposeIds in the same certificate.
> >
> 
> It has been pointed out to me that the very next paragraph of section 5.3
> states:
> 
> These requirements include all cross-certified certificates which chain to
> > a certificate that is included in Mozilla’s CA Certificate Program.
> >
> 
> The term "cross-certified certificates" could refer to the actual
> cross-certificate, or it could refer to intermediate certificates that
> chain up to the cross certificate. In the case of a root that is being
> cross-certified, the former interpretation effectively means that distinct
> cross-certificates would be required for serverAuth and emailProtection, as
> follows:
> 
> 1 - Root <-- Cross-certificate (EKU=emailProtection) <-- Intermediate
> certificate (EKU=emailProtection) <-- leaf certificate (S/MIME)
> 2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate
> certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS)
> 
> Should our policy require cross-certificates to be constrained to either
> serverAuth or emailProtection via EKU, or should this requirement only
> apply to [all other] intermediate certificates?
> 
> What is the correct interpretation of section 5.3 of the policy as
> currently written?
> 
> I would appreciate everyone's input on these questions.
> 
> - Wayne
> 
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/QIweY3cHRyA/vbtnfJ4zCAAJ

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

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Bruce via dev-security-policy]

On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> I think we have settled on the following resolution to this issue:
> 
> Add the following to section 5.2 (Forbidden and Required Practices):
> 
> CAs MUST NOT generate the key pairs for end-entity certificates that have
> > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> > anyExtendedKeyUsage.
> >
> > PKCS#12 files must employ an encryption key and algorithm that is
> > sufficiently strong to protect the key pair for its useful life based on
> > current guidelines published by a recognized standards body. PKCS#12 files
> > MUST be encrypted and signed; or, MUST have a password that exhibits at
> > least 112 bits of entropy, and the password MUST be transferred using a
> > different channel than the PKCS#12 file.
> >
> 
> Unless there is further discussion, I will include this language in the
> final version of the policy.
> 
> - Wayne

In one use case, the Subscriber can create their own password to start the 
enrollment process for the S/MIME certificate. The P12 is created, encrypted 
and sent to the Subscriber to be decrypted using the password. I think that 
asking the Subscriber to create a password with 112-bits entropy may create a 
very long password (over 20 characters). I think that this will take much 
longer than the life of the certificate (or its user) to crack. This password 
may also be recorded improperly or recorded on the same device as the key will 
reside. Could we consider reducing the size of the password?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audits for new subCAs

[Bruce via dev-security-policy]

Entrust does the following:
- Each subCA certificate is created through a audited ceremony. The auditor 
creates a report indicating the key ID and the CPS which was used for key 
generation.
- When it is time for the subCA to go into production, an intermediate 
certificate is issued from a root. The intermediate certificate will meet the 
requirements of the CPS and the BRs if applicable.
- The subCA can now issue certificates. The end entity certificates will have a 
certificate policy which is stated in the CPS. As such, issuing a certificate 
is an assertion that the subCA is issuing in accordance with the certificate 
policy and CPS.
- The new subCA is compliance audited at the next time in our annual audit 
cycle. Note the new subCA is operated the same as all other CAs meeting the 
same certificate policy.

I would note that if there was a significant change such as data center 
location or new certificate policy, then we may want to consider a 
point-in-time readiness assessment. I think that all CAs required a 
point-in-time readiness assessment, before we started to issue EV certificates.

I suppose that I am stating that I support option 1 as I think the option 2 
attestments are already covered. However, option 3 may be required for a new 
data center or a policy which has not been previously audited.

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

Incident Report - IP Address in dNSName form

[Bruce via dev-security-policy]

Entrust issued two certificates where the IP Address was indicated in the 
dNSName form. Both certificates have been revoked. The bug has been resolved.

Details of the incident report can be found here, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1448986.


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

Re: Incident report: Failure to verify authenticity for some partner requests

[Bruce via dev-security-policy]

On Wednesday, January 10, 2018 at 4:24:54 PM UTC-5, Tim Hollebeek wrote:
 
> As you know, BR 3.2.5 requires CAs to verify the authenticity of a request
> for an OV certificate through a Reliable Method of Communication (RMOC).
> Email can be a RMOC, but in these cases, the email address was a constructed
> email address as in BR 3.2.2.4.4.  Despite the fact that these addresses are
> standardized in RFC 2142 or elsewhere, we do not believe this meets the
> standard of "verified using a source other than the Applicant
> Representative."

I agree. The intention for the constructed email from BR 3.2.2.4.4 was supposed 
to be to "confirm the Applicant's control over  the FQDN" and not to perform 
the BR 3.2.5 requirement "to verify the authenticity of the Applicant 
Representative’s certificate request."

I also don't think a CA should use the information from 3.2.2.4.2 (Email, Fax, 
SMS, or Postal Mail) or 3.2.2.4.3 (phone number) to get the BR 3.2.5 
authorization. The issue is the CA may end up using the same data to perform 
both 3.2.2.4 and 3.2.5 and will not mitigate the risk that the attacker 
controls the WHOIS data.

It would be more secure if the CA used two separate methods of communication 
for 3.2.2.4 and 3.2.5.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Unknown Intermediates

[Bruce via dev-security-policy]

On Friday, June 16, 2017 at 1:05:37 AM UTC-4, Tavis Ormandy wrote:
> Hello, I was crawling the pkcs7 blobs in public pdf files and found some
> intermediate certificates that don't appear in crt.sh.
> 
> I forwarded them to Rob, I don't know if this is useful to anyone else, but
> they're available here.
> 
> https://lock.cmpxchg8b.com/intermediates.zip
> 
> Tavis.
> 
> (I have a larger collection if anyone wants them, but many have unknown
> critical extensions, or are name or usage constrained, etc)

I'm trying to understand this posting. I think the CAs have an obligation to 
disclose all Intermediate certificates to the CCADB. I don't think that the CAs 
have an obligation to disclose through CT. Am I right?

I did review the zip above and found 3 Entrust/AffirmTrust certificates. These 
were all disclosed in the CCADB. 

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