RFP, 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
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
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
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
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
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
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
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
>
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
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
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
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
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 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
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 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.
>
>
> 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 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://
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=cablint
>
> Sub-CA under DigiCert
> https://crt.sh/?id=12460684=cablint
>
> Sub-CA under
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)
> >
> - 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
>
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
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
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
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
I don't understand. The domain owner/admin is not a third party.
-Rick
On Jun 10, 2015, at 4:01 AM, Hubert Kario hka...@redhat.com 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:
True, OTOH, if a third party
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 course
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 frequently might such tools run? Or to put
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 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 Andrews wrote:
Ryan, they're not, but the root
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
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, 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
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
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.
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 the
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
38 matches
Mail list logo
