On this page, a sub CA could refer to the organization holding an
intermediate certificate or an intermediate certificate. If the latter,
then I think you need to retain "third-party" to distinguish between
intermediates covered by the CAs own audit and those covered under a
separate audit.
Jer
Strongly disagree that the security benefits are illusions. Granted, they
are not as great as with hard fail, but they do provide some benefits over
absolutely no revocation mechanisms. Even with the soft-fail methods
currently used, they at least require an extended isolation of the user from
th
There are lots of occasions:
1) Where a server with a private key is missing but there isn't yet an
active attack
2) Where the key was compromised
3) Where an error occurred and the certificate information identified the
wrong entity
4) Where the certificate was issued in accordance with the then-a
+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jeremy Rowley
Sent: Monday, October 28, 2013 1:29 PM
To: 'Brian Smith'; 'Rick Andrews'
Cc: dev-security-policy@lists.mozilla.org
Subject: RE: Netcraft blog, violations of CABF Baseline Requirements, any
consequences?
There are
zilla
.org] On Behalf Of Brian Smith
Sent: Monday, October 28, 2013 1:43 PM
To: Jeremy Rowley
Cc: dev-security-policy@lists.mozilla.org; Rick Andrews
Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any
consequences?
On Mon, Oct 28, 2013 at 12:28 PM, Jeremy Rowley
wrote:
>
Hi Kathleen,
Can you clarify whether this applies only to third-party Sub CA certificates
or internal subordinate CAs? A lot of the inclusion policy seems applicable
only to external sub CAs. If the certificate is covered by our WebTrust
audit, is operated solely by DigiCert, and is only used a
I imagine every CA would agree with you. OCSP stapling is a great idea, but
the number of servers deploying it are very low. I don’t believe any CAs
support the idea of getting rid of revocation checking.
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicer
Sent: Friday, November 8, 2013 11:51 AM
To: Jeremy Rowley
Cc: fhw...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Mozilla not compliant with RFC 5280
I don't believe there are any parties who you would want as CAs that support
the idea of getting rid of revocatio
I do not think forward dating is a problematic practice. Forward dating is
common when you’re issuing shorter lived certs and dealing with countries where
the Internet is less stable. You want a collection of certs that you can
install on the server if the country’s external access is unavaila
I think this is a good idea. Per 5280, the notBefore date is used to
indicate the start of the certificate's validity (not the date it was
issued). Using a new optional extension for issuance date will avoid
causing technical problems with other systems and still let Mozilla enforce
the BRs.
--
If you are granting more time, I have a whole bunch of customers who are not
happy about the 2013 cutoff. Extending it for some CAs is patently unfair
to those of us who have taken a hard stance on the deadline and not
requested extensions of time. If you are granting some CAs an extension,
you'l
The requirement is from Mozilla's policy, not the BRs:
https://wiki.mozilla.org/CA:MD5and1024
Note that the Microsoft policy doesn't require revocation. Instead, they
required all CAs to stop issuing 1024 bit certs as of Dec 31, 2010
(http://technet.microsoft.com/en-us/library/cc751157.aspx). Th
ith a qualification because of non-revoked 1024 bit certs.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jeremy Rowley
Sent: Wednesday, December 11, 2013 6:01 PM
To: 'Rob Stradling'; 'Kathl
As outlined in the root inclusion request, we need to embed all five for
fully support our community. Here's why:
1) These root certificates are used in many different systems, not just
Mozilla. If Mozilla doesn't embed all of them, the ones not embedded will
essentially be untrusted. The roots
support, they
permitted us to include five roots.
Jeremy
-Original Message-
From: Eddy Nigg [mailto:eddy_n...@startcom.org]
Sent: Wednesday, January 29, 2014 2:34 PM
To: Jeremy Rowley; mozilla-dev-security-pol...@lists.mozilla.org
Cc: 'Gervase Markham'; 'Brian Smith';
Some comments:
>I agree with everything you say above: the PKIX should be a way of reliably
mapping between domain names and keys, and nothing more.
[JR] Incorrect. From 5280:
"The goal of this specification is to develop a profile to facilitate
the use of X.509 certificates within Internet
Also, I think most large CAs are using CDNs to serve responses, making OCSP
servers a less attractive target.
In addition to mitigating DoS attacks, deploying OCSP stapling solves any
privacy concerns.. This is one of many reasons all of the large CAs are
promoting it as a best practice.
Jeremy
The baseline requirements only apply to certificates intended for use in
SSL/TLS. CAs only offering client certs are not covered by the BRs but are
covered by the network security guidelines.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=di
+1. This is especially true in the federal space where some intermediates
are stored offline most of the time. Per Section 4.9.7 of the FBCA CP,
these CAs use a 31-day interval for status information. Bringing the CA
online to generate responses every 10 days will actually make those CAs less
s
Kathleen,
Can you explain #5 a bit? I apologize if this was previously answered, but
does this rule apply to all intermediates used by the CA itself or only
those existing outside of the CA's PKI? Seems like ones operated solely by
Te CA(and covered by the CA's audit) don't necessarily require
rt.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Monday, May 12, 2014 4:46 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DRAFT: May CA Communication
On 5/12/14, 2:24 PM, Jeremy Rowley wrote:
> Kathleen,
>
> Can you explain #5 a bit? I apologize if this was
e an issue
with the policy.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jeremy Rowley
Sent: Monday, May 12, 2014 5:07 PM
To: 'Kathleen Wilson'; mozilla-dev-security-pol...@lists
ley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Monday, May 12, 2014 5:39 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DRAFT: May CA Communication
On 5/12/14, 4:07 PM, Jeremy Rowley wrote:
> Won't this policy encourage bad naming practices in inter
n 5/12/14, 5:06 PM, Jeremy Rowley wrote:
>>From what I can tell, the new Mozilla policy covers both SSL and
>>client cert
> issuing intermediates. There are some interesting complications with
> client certs that some CAs may experience since client certs are often
> used on
nd get back to you.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham
Sent: Tuesday, May 13, 2014 7:08 AM
To: Jeremy Rowley; 'Kathleen Wilson';
mozilla-dev-
icy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Tuesday, May 13, 2014 8:20 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DRAFT: May CA Communication
On 5/13/14, 6:07 AM, Gervase Markham wrote:
> On 13/05/14 01:44, Jeremy Rowley w
o:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Tuesday, May 13, 2014 9:38 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DRAFT: May CA Communication
On 5/13/14, 8:32 AM, Jeremy Rowley wrote:
> Sorry - I mixed points
Communication
On 5/13/14, 8:46 AM, Jeremy Rowley wrote:
> That actually clears things up. Intermediate certs aren't required to
> have an EKU but, if they do and the intermediate will be used for SSL,
> they must have the id-kp-serverAuth (1.3.6.1.5.5.7.3.1) EKU.
>
>
I th
: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Communication - May 12, 2014
On Monday, 12 May 2014 13:45:16 UTC-6, Jeremy Rowley wrote:
> +1. This is especially true in the federal space where some
intermediates
>
> are stored offline most of the time. Per Section 4.9.7 of
She's clarified in the discussion thread that it is all SubCAs chained to
the a CAs root certificate that must be disclosed, regardless of who
controls the private key.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists
Cool. It's good to see that the number of certs with these issues has
declined significantly, especially considering the valid from date. Have you
emailed the CAs issuing these certs to let them know they might have
issuance issues?
-Original Message-
From: dev-security-policy
[mailto:dev
I saw that he's contacting CAs about the missing SANs, but what about the
other issues? I'd be very interested in hearing about any non-compliant
certs related to DigiCert (if there are any).
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.r
Please do!
-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be]
Sent: Tuesday, May 20, 2014 2:22 PM
To: Jeremy Rowley
Cc: 'Kathleen Wilson'; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Checking certificate requirements
On Tue, May 20, 2014 at 12:31:
I think getting them revoked would be the first step. If you make the data
available about which CAs still have 1024 bit certs or lower, we could email
the CAs and find out what is going on.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.ro
Right - under the BRs there is supposed to be a "Pre-Issuance Readiness
Audot" that confirms the CA's readiness to comply with the BRS.
Unfortunately, the pre-readiness audit is not well defined, but it should
include a practical demonstration that when issuance begins, the BRs will be
followed in
We'd support that motion in the CAB Forum. In fact, I last time we discussed
this, a majority of CAs supported requiring the BR/EV OIDs in certificates. If
Mozilla would vote in favor of such a motion, the proposal would likely pass.
Jeremy
-Original Message-
From: dev-security-policy
Right - all adding the OIDs does is specify in the certificate which BR section
was used to perform the validation. There isn't a security indicator attached.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozill
Ryan Hurst wrote a blog post on this very topic not too long ago. His
conclusion was that determining, programmatically, the difference was
difficult. See http://unmitigatedrisk.com/?p=203.
This is mostly because there are some certs that still include a domain in the
org field. Requiring a
I agree he was in favor of requiring the BR OIDs, as I think most CAs are.
Jeremy
-Original Message-
From: Moudrick M. Dadashov [mailto:m...@ssc.lt]
Sent: Wednesday, July 23, 2014 9:02 AM
To: Jeremy Rowley; 'Robin Alden'; 'Gervase Markham'; nick.l...@lugate
It makes a difference because you can tell whether the CA is operating
effective polices in accordance with the BRs. Too many DV certs hold
themselves out as OV certs without actually providing the verification under
the BRs. Requiring the BR OIDs is an assertion by the CA of compliance that is
Except when CAs don't make the assertion themselves. We've already been over
the fact that "intended for use in SSL" is so ambiguous that the BRs don't
provide assurances over what the CA does. The OIDs are an assertion that the
cert is intended for use in SSL. You can tell which BR version t
I do not think specifying a version number is required. All CAs issuing EV
certs (or SSL) are required to abide by the latest version of the guidelines
and attest to that fact in their CPS using the prescribed CAB Forum language:
"[Name of CA] conforms to the current version of the CA/Browser
e certificate is an assertion of compliance with the latest version of the
guidelines, meaning versioning is largely irrelevant.
Jeremy
-Original Message-
From: Ryan Sleevi [mailto:ryan-mozdevsecpol...@sleevi.com]
Sent: Sunday, July 27, 2014 9:11 PM
To: Jeremy Rowley
Cc: '
This is great. Thanks Richard!
For OneCRL and the EE certs, establishing parameters around when an EE is
eligible for inclusion would give guidance to CAs about when to report
revocations. Is the OneCRL intended for when the cert is compromised because
of a breach of the CA? Or can high pr
Some information on performance is available here:
http://ocspreport.x509labs.com/. You might be able to reach out to them and
get the actual data related to number of failed responses.
Whether fails and speed are major issues depends on who you ask.
Jeremy
-Original Message-
Fro
Why does OneCRL seem like a hack? Considering how infrequently intermediates
and roots are revoked, OneCRL seems like a satisfactory way to provide this
information long-term, provided that the certs are removed from OneCRL at some
point. I'd think they could safely remove the OneCRL certs aft
Seems like a lot of anecdotes are being shared with respect to hard fail
without a lot of data. Do the browsers have more data on this? Considering
the X.509 labs shows nearly 100% availability with response times of about 100
ms, data showing in-depth info on failure rates (and the reasons wh
, 2014 10:35 AM
To: Jeremy Rowley
Cc: Matthias Hunstock; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New wiki page on certificate revocation plans
Firefox 31 data:
on desktop the median successful OCSP validation took 261ms, and the 95th
percentile (looking at just the universe of
I think most CAs use CDNs to help serve OCSP responses quite fast and reliably.
A breakdown of failure rates based on certificate provider could provide
insight on what's going on. Is gathering this information too close to
violating a user's privacy for Mozilla? Any chance of peering into this
The cert is allowable as long as the root is 1024, not the end entity. The end
entity must be 2048 under the current Mozilla requirements.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
On Behalf O
The CAB Forum released a proposed new baseline requirements around code signing
today that might be of interest to participants here. You can see the document
here:
https://cabforum.org/2014/08/25/cabrowser-forum-releases-code-signing-baseline-requirements-public-comment-draft/
Public comments
If the cert was issued directly from a 2048-bit root and the issuance date is
after the effective date of the BRs, then the cert violates the BRs and there
should be an explanation.
Although notBefore != issuance date, if the notBefore date is earlier than Feb
2013 and the root is 2048, then th
e separate sets of keys.
Jeremy
-Original Message-
From: fhw...@gmail.com [mailto:fhw...@gmail.com]
Sent: Friday, August 29, 2014 7:39 AM
To: Jeremy Rowley; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Code Signing Draft
Thanks for sharing this Jeremy. I'm still rea
ecpol...@sleevi.com]
Sent: Friday, August 29, 2014 12:44 PM
To: Jeremy Rowley
Cc: 'fhw...@gmail.com'; mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Code Signing Draft
On Fri, August 29, 2014 8:04 am, Jeremy Rowley wrote:
> Good point. I don't think we spell it out, b
An exception to Mozilla's policy won't permit short-lived certificates since
the other browsers won't have the same exception. Personally, I like 0 the
best since it coordinates all of the CAs and browsers into a single plan of
action rather than carving out individual exceptions to the guideli
They aren't subject to less stringent security in issuing the certificate. The
benefit is that the certificate doesn't include revocation information (smaller
size) and doesn't need to check revocation status (faster handshake). The
issuance of the certificate still must meet all of the Mozilla
org
Subject: Re: Short-lived certs
On 9/4/2014 10:44 AM, Jeremy Rowley wrote:
>
> They aren't subject to less stringent security in issuing the
> certificate. The benefit is that the certificate doesn't include
> revocation information (smaller size) and doesn't
Yeah - the cert would have to be shorter than the longest acceptable OCSP
response for certificates. I think that's set to 10 days in the CAB Forum, but
I'd be surprised if anyone issues OCSP responses that are valid that long.
The issue of revocation checking is where the proposal died in the
I agree with Ryan - as long as Mozilla (or the CAB) isn't requiring short
lived certs, there isn't a concern about legacy servers. Since short-lived
certs are optional, each server operator can individually decide on their own
whether to implement short-lived certs on their server.
Also, b
kely
give site visitors sufficient notice that something is going wrong.
Jeremy
-Original Message-
From: fhw...@gmail.com [mailto:fhw...@gmail.com]
Sent: Thursday, September 4, 2014 12:33 PM
To: Jeremy Rowley; 'David E. Ross';
mozilla-dev-security-pol...@lists.mozilla.org
Subj
I agree that we should reduce the validity period of OCSP responses and also
that must staple is a high priority. 10 day responses is way too long
(although I doubt any CAs are actually doing 10 days).
Mozilla appears to be considering their entire revocation policy at this time,
including fut
Hi Richard,
I like the concept of promoting better security practices through an
indicator or other means. I especially like the idea of providing a
coordinated effort between multiple members of the security community to
ensure everyone is informed, working towards a common goal, and
promot
I wouldn't be worried about a browser rejecting a cert that doesn't
comply. Instead, I'd be worried about a qualified audit showing
non-compliance. Although Mozilla might not care about that particular
non-compliance, other browsers and partners might.
Jeremy
On 9/22/2014 8:36 AM, Gervase Ma
A couple of notes:
1) Under Section 3.4 and 4.9, suspension is not permitted for SSL certs
under the BRs.
2) Section 3.3 should specify when re-verification is required (at least
every 39 months). Although the CPS does say the original issuance
process is followed, I didn't this specified at t
If you look under Section 13.2.4, a CA cannot remove an entry from its
CRLs, meaning there is no way to un-suspend a certificate.
On 9/25/2014 7:03 AM, Certificates wrote:
Answers for Jeremy Rowley questions:
A couple of notes:
1) Under Section 3.4 and 4.9, suspension is not permitted for SSL
Also, policy and authorization is often embedded in client certs.
Software that knows how to read this information can provide permissions
based on the included policy. This is used by first responders and large
distributed networks where the credential acts as their permission to
participate a
@lists.mozilla.org]
On Behalf Of Przemyslaw Rawa
Sent: Friday, September 26, 2014 7:31 AM
To: dev-security-policy@lists.mozilla.org
Subject: KIR S.A. Root Inclusion Request
Answer for suspension and OCSP issues (Robin Alden and Jeremy Rowley):
RFC 5280 allows suspension. In our opinion, suspension is a usefull
I think you should clarify what constitutes a "document confirming rights to
the domain". Is this authorization from the registrar or registrant? Who
provides the document?
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@list
Right - you can parse CRLs into deltas as long as they include an IDP.
Jeremy
On 10/3/2014 11:26 AM, Erwann Abalea wrote:
> >The CRLNumber numbering has been restarted from 1, and the revoked certifica
___
dev-security-policy mailing list
dev-securi
As you know, the CAB Forum guidelines do not mandate use of CAB Forum policy
OIDs to assert DV/OV compliance. We'd happily support a change in this policy
at the CAB Forum and plan to update our certs accordingly if such ballot passes.
Jeremy
-Original Message-
From: dev-security-policy
Comodo offers 3 levels:
DV - PositiveSSL
OV - InstantSSL
EV - EV SSL
DigiCert (as well as the EU CAs as you mentioned) only offers two levels - OV
and EV.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.o
Correct - we (DigiCert) reserved the OID but don't issue certs under it.
Jeremy
On 10/29/2014 3:41 PM, John Nagle wrote:
On 10/29/2014 01:40 PM, Jeremy Rowley wrote:
Comodo offers 3 levels:
DV - PositiveSSL
OV - InstantSSL
EV - EV SSL
Comodo's CPS is at
https://www.comodo.com/
This list is missing a security audit. I'd recommend the a network
security audit (or something else) that provides some assurance of
network security.
Since the BRs are explicitly referenced by the EV Guidelines (and
incorporated therein), why not require a BR audit plus EV for an EV
hierar
Some initial thoughts:
1) Membership in the CAB Forum is not required for a CA to commit to complying
with the BR, and if non-membership avoids any obligation to comply with the
BRs, I think you'll quickly see a mass exodus from the group. No member of the
CAB Forum is bound to its requirement
> Some initial thoughts:
>
> 1) Membership in the CAB Forum is not required for a CA to commit to
> complying with the BR, and if non-membership avoids any obligation to comply
> with the BRs, I think you'll quickly see a mass exodus from the group. No
> member of the CAB Forum is bound to its
Kurt said "I think that the webtrust audit is also based on a certain version
of the BR and that they might not have been updated yet to check the latest
version. So I think the audit report should indicate which version was
checked. If an audit was not for the last version that doesn't mean C
Snipped to try and make the convo less confusing.
[MH] If that's the case, the trustworthiness of a Webtrust audit would be
weakened. Auditors should obtain the CA's assertion of compliance, and assess
whether it's reasonable with respect to the CA's CP/CPS and the target scope of
audit (i.e.
Just one thought - Richard Barnes involvement with Let's Encrypt makes it look
like Mozilla is promoting its own CA over the others. If there's any question
on Let's Encrypt getting favoritism, Mozilla will be opening itself up to an
anti-trust lawsuit, especially in Europe where vertical integr
I dislike the idea. Other CAs contribute to the discussion but should not the
gatekeeper. Ryan Sleevi makes complete sense since Google uses the NSS store.
Commercial CAs actually having a say on another CA's inclusion (outside of the
current public discussion) seems like something that should
+1 to Ryan's comments. The plan locks small CAs into being small while letting
big CAs continue to dominate the market. It basically prevents new CAs for
even entering the market.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.
Not to mention, that the lack of a required OCSP URI (with a stapled response)
is something that the forum has talked about correcting a few times. It's
likely going to be required (hopefully with an exception for short lived certs).
Jeremy
-Original Message-
From: dev-security-policy
Although CT would not have prevented issuance, requiring CT for all
certificates would have detected the misissuance much sooner. Maybe Mozilla
should be the first to require CT for all certificates?
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounce
I'm not sure that would be in scope for the right key list anyway. It's also
probably more policy and business logic than an actual technical discussion,
meaning IETF is probably not the right revenue.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jer
We update ours annually. A new one is about to be posted.
Eugene wrote:
According to the CA Baseline Requirements section 8.2.1, "The CA SHALL develop,
implement, enforce, and **annually update** a Certificate Policy and/or
Certification Practice Statement that describes in detail how the CA
Should have read your email more carefully. Yes all cas are required to update
annually. Those that don't are out of compliance. I think its even one of the
criteria under webtrust.
Eugene wrote:
According to the CA Baseline Requirements section 8.2.1, "The CA SHALL develop,
implement, enfor
And to make sure they at least looked at it. If nothing changed, then you can
simply update the date and republish.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
On Behalf Of Kurt Roeckx
Sent: Monday, Apri
You're misreading the EV Guidelines. The certificate approver represents the
applicant, not the CA, and is the individual authorized to say "Yes, Mozilla is
really the entity requesting the certificate". To address your concerns:
The people responsible for the DigiCert root cert (or any root c
I agree with Steve. Being able to compare CP documents readily is the point
behind the 3647 format. We converted the BRs to 3647 so members can compare
their CPS side-by-side with the BRs and see where there is a deficiency.
Comparing the Mozilla policy in a 3647 would make the CPS reviews and
While interesting, this report is probably going to be used for a lot of
misleading statements. There's lots to consider in this:
1) Considering that the 3-year validity cap was a recent requirement, I'm
surprised your search only resulted in 50,000 certificates with all of the 5-10
year certi
Encoding an IP Address in a dNSName is not permitted by the BRs. This is what
Peter's "_ipv4_not_allowed_here" rule refers to, IIUC.
[JR] I suppose that is true under 7.1.4.2.1 but how would you get the browsers
to work back then? Chrome and IE did not process ipAddress properly.
Jeremy
> Rega
rob.stradl...@comodo.com]
Sent: Tuesday, November 17, 2015 2:12 PM
To: Jeremy Rowley
Cc: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org; Peter Bowen;
Peter Gutmann
Subject: Re: [FORGED] Name issues in public certificates
On 17/11/15 18:27, Jeremy Rowley wrote:
> Encoding an IP Address in
These are all things the auditors control, not necessarily CAs. Enacting
something like this would require WebTrust and ETSI buy-in to update the
templates and information. If you said the CA must clearly indicate in their
submission that X, Y, and Z must happen, then it makes more sense (as th
Thanks we are investigating. This was a SubCA that existed well before our
acquisition of the Baltimore roots. We are contracting the customer and are
requesting a full report.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice
Same with DigiCert. This is a sub CA issued by Verizon. We've reached out
to the customer to investigate why they had the issue and what they are
doing to remediate. We will provide details once we receive them.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bo
: Wednesday, February 3, 2016 9:05 PM
To: Jeremy Rowley
Cc: Rick Andrews; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: More SHA-1 certs
Are CAs really not monitoring issuance of certs by their sub-CAs for simple
violations like this? Does this not violate a Mozilla or CAB Forum policy
I don't think we should have to use a competitor's product to evaluate this.
Are we permitted to set up our own instance of this using the open source to
do the testing? There should be that option considering IP rights have not
been freely granted on all this software.
-Original Message-
I think Rob's questions are great and should be answered before deciding.
Many CAs have roots and can issue certs that browsers will simply reject.
There may be a simple way to provide them certs without issuing a ton of
SHA1s that are placed on OneCRL.
-Original Message-
From: dev-securit
rkham [mailto:g...@mozilla.org]
Sent: Wednesday, February 24, 2016 9:11 AM
To: Jeremy Rowley; Rob Stradling;
mozilla-dev-security-pol...@lists.mozilla.org
Cc: Kathleen Wilson; Richard Barnes
Subject: Re: Proposed limited exception to SHA-1 issuance
On 24/02/16 15:45, Jeremy Rowley wrote:
> I thi
Technically, Worldpay had a lot longer than four days to figure this out
It's not like SHA1 issues jumped out from a behind a bush to scare everyone.
I believe the concern is that Worldpay is asking for an exception by saying,
"We've tried 'things' and they didn't work - can we please have a
The RFC says "misissuance of a precertificate is considered equal to
misissuance of a final certificate". This raises an interesting question. Pre
certificates are not required to comply with the Cab forum's BRs as they fall
out of scope (not intended to be used for TLS authentication). Sha1 cer
1 - 100 of 465 matches
Mail list logo
