Is there any detailed explanation (perhaps similar to this page:
https://developer.mozilla.org/en-US/docs/Introduction_to_Public-Key_Cryptography)
that describes how NSS chooses among multiple valid chains for SSL certs (for
example, when an SSL server returns a cross certificate that could be u
> Yes, surely only someone insidious and evil and who hates Freedom would
>
> ever support such an security-hostile idea as a 1-4KB OCSP response,
>
> rather than a 50MB CRL. It's likely that the Legion of Cryptographic Doom
>
> have compromised OCSP, likely using the World Bank to infiltrate t
Brian, you seem to be saying that revocation checking adds value only when
there's an attacker involved. If that's your point, I disagree. There are cases
in which a CA revokes a certificate because the site has misrepresented itself,
and revocation serves as a warning to the client.
___
I'd like to explore how "Notification shall be made in an authenticated and
trusted manner". Kathleen's wiki page says to send email to
secur...@mozilla.org or file a bug. How would Mozilla determine that the
request was legitimate?
I suspect that Mozilla already maintains a short list of conta
I noticed that Wikipedia lists EV OIDs
(http://en.wikipedia.org/wiki/Extended_validation).
If any are missing, it's easy to update that page.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/d
Brian, Kathleen,
The idea of removing Firefox's ability to fetch an OCSP response from a CA
seems to me to be a significant policy shift. But it's being discussed here in
this thread (with an unrelated Subject line) which many may miss. Why not add
it to https://wiki.mozilla.org/CA:ImprovingRev
Kathleen, I think that even if you agree to extend the deadline, it's a moot
point unless Microsoft and other browsers follow suit. Unless there are web
site owners that only support Firefox.
___
dev-security-policy mailing list
dev-security-policy@list
Kai, I can give you a little history to explain our actions.
Although it's clear today that there's (at least) two classes of users for SSL
certificates, browsers and non-browsers (devices like POS terminals, TVs,
etc.), that's not always been the case. For years, we (and I'm sure other CAs)
ha
Since support for CRLs has been removed from Firefox, why does Mozilla's root
policy
(http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/)
require CAs to maintain and publish CRLs?
Is it because Mozilla intends to build CRLs sets in the future?
__
Kathleen, that means we'll be disclosing a number of intermediates used to sign
certificates that are not used for SSL, Code Signing or Mail (the three trust
bits that Firefox lets me view/edit). For example, we issue a lot of client
auth certs from our public roots.
Based on your previous comm
On Tuesday, May 20, 2014 11:33:17 AM UTC-7, Kathleen Wilson wrote:
> On 5/20/14, 11:08 AM, Kathleen Wilson wrote:
>
> > On 5/19/14, 9:40 AM, Rick Andrews wrote:
>
> > > Kathleen, that means we'll be disclosing a number of intermediates
>
> > > used t
Ryan, they're not, but the root is not trusted for SSL (via meta-data). AFAIK,
Firefox won't trust any SSL cert chaining to it. Will Chrome?
-Rick
---
Rick,
Are these subordinate CAs technically constrained, according to the terms of
Mozilla's CA Certificate Pol
On Thursday, May 22, 2014 11:22:17 AM UTC-7, Kathleen Wilson wrote:
> On 5/21/14, 5:02 PM, Kathleen Wilson wrote:
>
> > On 5/21/14, 2:54 PM, Ryan Sleevi wrote:
>
> >> On Wed, May 21, 2014 12:12 pm, Kathleen Wilson wrote:
>
> >>> On 5/20/14, 9:53 AM, Rick
Kathleen, why is mozilla.org still using a SHA-1 cert?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
> True, OTOH, if a third party says that there was a misissuance, that means
> there was one.
I disagree. Only the domain owner knows for sure what is a misissuance, and
what isn't. It seems likely that I might turn over all known
On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
> On 2015-06-09 15:26, Peter Kurrasch wrote:
> > 3) How frequently might such tools run? Or to put it differently, how much
> > time do I probably have between when I issue a gmail cert and when someone
> > figures it out (and of co
On Tuesday, June 9, 2015 at 12:23:57 PM UTC-7, Kurt Roeckx wrote:
> On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote:
> > On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
> > > On 2015-06-09 15:26, Peter Kurrasch wrote:
> > > > 3) How frequ
I don't understand. The domain owner/admin is not a third party.
-Rick
> On Jun 10, 2015, at 4:01 AM, Hubert Kario wrote:
>
>> On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote:
>>> On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
>>> Tru
On Tuesday, August 4, 2015 at 2:05:47 PM UTC-7, Kathleen Wilson wrote:
> On 8/4/15 1:26 PM, Peter Bowen wrote:
> > On Tue, Aug 4, 2015 at 1:17 PM, Kathleen Wilson wrote:
> >> The Included CAs list is now being automatically generated directly from
> >> Salesforce:
> >>
> >> https://mozillacaprogram
Kathleen, I'll admit that I'm discouraged from contributing. Can you tell us
what if anything is being done to keep the discourse at a more respectable
level?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozil
On Tuesday, October 13, 2015 at 5:16:10 PM UTC-7, Charles Reiss wrote:
> On 10/13/15 18:46, Kathleen Wilson wrote:
> > In September of this year, the CA Symantec revealed[0] that they had
> > mis-issued
> > a number of certificates for domains that they did not own or control, for
> > testing purp
Rob, Gerv - Thanks for your input. We are collating all feedback and are
planning to publish another update soon.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
We are working hard on providing an update and responding to open questions.
We will provide further information as soon as its available.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-
We have just posted an update to our test certificate incident report at
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_20151029.pdf.
With regard to the questions on the certificates identified in this
discussion, we have reviewed these and we
> - We are re-evaluating when we should start rejecting all SHA-1 SSL
> certificates (regardless of when they were issued). As we said before,
> the current plan is to make this change on January 1, 2017. However, in
> light of recent attacks on SHA-1, we are also considering the
> feasibilit
On Wednesday, November 18, 2015 at 5:43:57 PM UTC-8, Brian Smith wrote:
> Peter Bowen wrote:
>
> > 2) For commonName attributes in subject DNs, clarify that they can only
> > contain:
> >
> - IPv4 address in dotted-decimal notation (specified as IPv4address
> > from section 3.2.2 of RFC 3986)
> >
On Sunday, January 31, 2016 at 9:47:53 AM UTC-8, Peter Bowen wrote:
> These are all in the last week
>
> Sub-CA under SHECA (which has applied to be in the Mozilla program)
> https://crt.sh/?id=12367776&opt=cablint
>
> Sub-CA under DigiCert
> https://crt.sh/?id=12460684&opt=cablint
>
> Sub-CA un
On Monday, February 1, 2016 at 10:34:18 AM UTC-8, Rick Andrews wrote:
> On Sunday, January 31, 2016 at 9:47:53 AM UTC-8, Peter Bowen wrote:
> > These are all in the last week
> >
> > Sub-CA under SHECA (which has applied to be in the Mozilla program)
> > https://crt.
> I would note that we could also combine these responses. For example, we
> might require that CAs retire SHA-1 for OCSP with a long-ish horizon, but
> require them to use constrained OCSP certs basically ASAP.
>
> Of course, if we could just turn off SHA-1 for OCSP, that would be
> fantastic.
On Tuesday, April 12, 2016 at 11:00:11 AM UTC-7, Kathleen Wilson wrote:
> It was pointed out to me that it was not clear that the dates I am asking for
> in ACTION #1a and ACTION #1b are regarding issuance of end-entity SHA-1 SSL
> certs. So, I added "(end-entity)" to both, as follows.
>
> "ACTI
On Wednesday, April 13, 2016 at 8:33:33 AM UTC-7, Kathleen Wilson wrote:
> On Tuesday, April 12, 2016 at 12:29:16 PM UTC-7, Rick Andrews wrote:
> > On Tuesday, April 12, 2016 at 11:00:11 AM UTC-7, Kathleen Wilson wrote:
> > > It was pointed out to me that it was not clear t
On Thursday, April 21, 2016 at 3:35:55 AM UTC-7, Ryan Sleevi wrote:
> On Wednesday, April 20, 2016 at 5:53:28 PM UTC-7, Matt Palmer wrote:
> > It seems fairly dysfunctional if a single member of the CA/B Forum can
> > prevent a ballot from going ahead.
>
> To be clear: That is not the same as what
On Thursday, April 21, 2016 at 9:15:43 AM UTC-7, Rick Andrews wrote:
> On Thursday, April 21, 2016 at 3:35:55 AM UTC-7, Ryan Sleevi wrote:
> > On Wednesday, April 20, 2016 at 5:53:28 PM UTC-7, Matt Palmer wrote:
> > > It seems fairly dysfunctional if a single member of
On Wednesday, April 20, 2016 at 12:47:58 PM UTC-7, Charles Reiss wrote:
> On 04/13/16 23:12, Kathleen Wilson wrote:
> > Request to enable EV for VeriSign Class 3 G4 ECC root
> >
> > This request by Symantec is to enable EV treatment for the "VeriSign
> > Class 3 Public Primary Certification Author
On Friday, April 22, 2016 at 6:41:46 AM UTC-7, Richard Barnes wrote:
> That is not the criterion, Rick. The criterion is "capable of being used
> to issue new certificates":
>
> """
> All certificates that are capable of being used to issue new certificates,
> and which directly or transitively c
GSA which governs FPKI recently approved Symantec’s proposal for one-way
cross-certification with the FBCA and to remove the cross-certificate from the
Symantec CA to the FBCA. The cross certificate is expiring on June 31, 2016 and
Symantec does not intend to renew the certificate going forward.
On Friday, July 8, 2016 at 4:21:27 PM UTC-7, Rick Andrews wrote:
> GSA which governs FPKI recently approved Symantec’s proposal for one-way
> cross-certification with the FBCA and to remove the cross-certificate from
> the Symantec CA to the FBCA. The cross certificate is expiring o
On Tuesday, July 19, 2016 at 1:05:13 PM UTC-7, Andrew Whalley wrote:
> Greetings,
>
> I have run the tool provided by dr.ir. Marc Stevens [1] on the
> tbsCertificates provided by Symantec [2]
>
> And see no evidence of collisions:
>
> $ ./sha1dcsum_partialcoll *.tbs
> 6ead26663275c388662dfdbc23f
On Friday, November 4, 2016 at 4:49:28 AM UTC-7, Gervase Markham wrote:
> On 03/11/16 18:09, Andrew Ayer wrote:
> > This is just as bad as signing an actual cert with SHA-1.
>
> Add:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315225 (Symantec)
>
> Gerv
I updated the bug to say that this was
Kathleen, https://bugzilla.mozilla.org/show_bug.cgi?id=1269332 is not a BR
violation. Kurt suggested we remove explicitText, but it's just a suggestion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/
Thanks for finding this, Nick. We're in the process of revoking the cert you
found, and searching for any others. We'll get back to you when we're done.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org
We conducted a search of our databases in September 2016, in which we examined
every CN and SAN in every certificate still valid at the time. Each CN and SAN
was examined to see if it contained no dot or an invalid DNS suffix; if so, the
certificate was classified as an internal server cert and
I'm posting this on behalf of Symantec:
We would like to update the community about our ongoing dialogue with Google.
Following our May 4th post, senior executives at Google and Symantec
established a new dialogue with the intention to arrive at a new proposal for
the community that addresse
On Thursday, July 20, 2017 at 12:31:56 PM UTC-7, Gervase Markham wrote:
> Hi Steve,
>
> Thanks for posting this. I appreciate the level of detail provided,
> which is useful in giving us a basis for discussion. It's a little
> regrettable, though, that it was published a couple of weeks after we
>
On Friday, July 21, 2017 at 12:07:02 PM UTC-7, Alex Gaynor wrote:
> On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin wrote:
>
> > 1) *December 1, 2017 is the earliest credible date that any RFP
> > respondent can provide the Managed CA solution proposed by Google, assuming
> > a start date of Au
P, and we have received no subsequent information from this bidder to
> > increase our confidence.
>
> You note that this assumes a start date of June 12. A later email
> from Rick Andrews says "Our proposed dates assume we are able to
> finalize negotiation of contracts with the
On Monday, July 24, 2017 at 2:50:22 AM UTC-7, Gervase Markham wrote:
> Hi Rick,
>
> Some more thoughts on your post. I continue to invite community
> commentary on the issues we are discussing.
>
> On 21/07/17 07:00, Rick Andrews wrote:
> > In our June 1 post, we stated
On Wednesday, July 26, 2017 at 10:20:08 AM UTC-7, Alex Gaynor wrote:
> On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy
> wrote:
>
> > Symantec has proposed timing changes that are consistent with the scope of
> > distrust of the original SubCA proposal
48 matches
Mail list logo
