On Fri, May 2, 2014 at 1:09 PM, Kathleen Wilson kwil...@mozilla.com wrote:
On 5/2/14, 11:17 AM, Peter Bowen wrote:
On Fri, May 2, 2014 at 10:05 AM, Kathleen Wilson kwil...@mozilla.com
wrote:
In regards to action #5, I think we need to add another option to allow CAs
to specify if they have
On Tue, May 13, 2014 at 11:45 AM, David Keeler dkee...@mozilla.com wrote:
On 05/13/2014 06:48 AM, Peter Bowen wrote:
I think the biggest question probably is id-kp-clientAuth. From a
quick scan of the NSS certdb code, it seems that setting this EKU in a
CA cert would allow it to issue
On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham g...@mozilla.org wrote:
On 04/08/14 18:16, Erwann Abalea wrote:
OCSP is painful and costly to optimize, x509labs shows great
availability and good performance for most CA/location combination,
but this is in contradiction with real user
On Wed, Aug 13, 2014 at 11:16 AM, Kathleen Wilson kwil...@mozilla.com wrote:
2) BR point-in-time audits may not be sufficient.
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy
Any Certificate Authority being considered for root
On Wed, Aug 20, 2014 at 1:55 PM, fhw...@gmail.com wrote:
I've encountered a wildcard end-entity certificate on a live server that
chains directly to the root cert. There is no intermediate certificate and
the root is in the Mozilla trust store.
I assume this is a frowned upon practice that
On Tue, Aug 26, 2014 at 11:35 AM, Kathleen Wilson kwil...@mozilla.com wrote:
I am running into a problem with BR audit statements that list details about
issues that have been found.
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements
...The first BR audit for each CA and
On Tue, Aug 26, 2014 at 1:24 PM, Kathleen Wilson kwil...@mozilla.com wrote:
On Tue, Aug 26, 2014 at 1:09 PM, Kathleen Wilson kwil...@mozilla.com wrote:
BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support
legacy customer apps)
BR 13.2.6 - OCSP giving status “good” for
On Mon, Oct 27, 2014 at 10:58 AM, John Nagle na...@sitetruth.com wrote:
On 27/10/14 08:16, Ryan Sleevi wrote: snip If you're trusting
certificates to assert information about either the identity of the
entity behind the key or that the CA has done due diligence, well,
you're using certificates
On Wed, Nov 19, 2014 at 11:27 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Mark Atwood m...@mark.atwood.name writes:
So Mozilla et al have been giving CAcert the runaround for over 4 years now,
and then suddenly they create a more centralized less audited Let's Encrypt
shows up, and it's
There are currently spreadsheets for roots that are included in the
Mozilla trust store and roots have applied to be in the trust store.
Is there any tracking of roots that were removed? How about any time
one of the trust bits or EV policy IDs are removed? (I'm not sure
that the later has ever
On Mon, Feb 9, 2015 at 4:19 PM, Ryan Sleevi
ryan-mozdevsecpol...@sleevi.com wrote:
Section 3.2.2 describes a means for validating domain ownership that is
not described within Section 11.1.1 of the BR 1.2.3. In particular, it
uses the WHOIS information (described in 11.1.1 p3) in conjunction
[mailto:dev-security-policy-
bounces+steve.roylance=globalsign@lists.mozilla.org] On Behalf Of
Peter
Bowen
Sent: 15 March 2015 00:59
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Certificate Profiles
I've been trying to figure out what is required, forbidden, and optional
for X.509
On Wed, Mar 18, 2015 at 4:04 PM, Kathleen Wilson kwil...@mozilla.com wrote:
On 2/7/15 3:02 PM, Peter Bowen wrote:
There are currently spreadsheets for roots that are included in the
Mozilla trust store and roots have applied to be in the trust store.
Is there any tracking of roots that were
On Thu, Mar 19, 2015 at 4:39 PM, David Keeler dkee...@mozilla.com wrote:
On 03/19/2015 01:01 PM, Peter Bowen wrote:
Given this ratio, I find it very hard to believe that they would be
able to receive an audit report without qualifications that Mozilla
would deem unacceptable.
Maybe I'm
Today the Mozilla CA policy and the CAB Forum categorize CAs as either
Root CAs or Intermediate CAs. However the reality is that the line is
not always clear between the two and this leads to uncertainty of what
requirements apply in various circumstances. For example, the Baseline
Requirements
Anyin,
It seems that the mailing list strips attachments. I copied the ones
you attached to this message a shared location. They are at:
https://pzb-public-files.s3-us-west-2.amazonaws.com/B1.pdf
https://pzb-public-files.s3-us-west-2.amazonaws.com/B2.pdf
Thanks,
Peter
On Mon, Mar 23, 2015 at
On Wed, Mar 25, 2015 at 10:10 AM, Kathleen Wilson kwil...@mozilla.com wrote:
All,
I appreciate your thoughtful and constructive feedback on this situation.
The suggestions regarding the CNNIC root certificates that I've interpreted
from this discussion are as follows. These are listed in no
On Wed, Mar 25, 2015 at 12:20 PM, Gervase Markham g...@mozilla.org wrote:
On 25/03/15 17:45, Ryan Sleevi wrote:
That is, in a hypothetical world where E1 is pursued (for any CA), the CA
can simply backdate the certificate. They'd be non-compliant with the
Baseline Requirements, presumably, but
On Mon, Mar 30, 2015 at 2:22 PM, jjo...@mozilla.com wrote:
On Monday, March 30, 2015 at 8:34:47 AM UTC-7, Richard Barnes wrote:
As a compromise, however, I would be willing to add the CNNIC intermediates
to the Mozilla root list (F). [...] Rather, we should plan
to remove them after a fixed
On Sun, Mar 22, 2015 at 4:18 PM, Kathleen Wilson kwil...@mozilla.com wrote:
admin@domain
administrator@domain
webmaster@domain
hostmaster@domain
postmaster@domain
What do you all think?
(Note this is also in Baseline Requirements section 11.1.1)
It is hard to know
Steve,
Unless Peter is a member of the forum, the public list is a black hole, as
only members can post. The alternative, the questions list, is not
publicly readable, so is also a bad choice for open discussion.
Therefore, while this thread is not the appropriate place, this forum is
probably
On Tue, Feb 17, 2015 at 7:25 AM, Framarti francescomartin...@gmail.com wrote:
i'm working for a company that is issuing trusted SSL OV certificates as a
subsidiary CA. I was thinking about becoming a trusted root CA in order to
get rid of the fees per each issued certificate to be given to
On Wed, Mar 25, 2015 at 6:24 PM, Peter Kurrasch fhw...@gmail.com wrote:
Someone correct me if I'm wrong, but my understanding of the Superfish
debacle is that sites that have EV certs would get the green bar treatment on
other devices but not on the Lenovo devices where Superfish was
On Mon, Mar 23, 2015 at 9:41 AM, Robin Alden ro...@comodo.com wrote:
I wonder if the current publicity will lead all webmail providers to do a
review, and then we won't see any further problems...
That would be nice!
Pertaining to Peter Bowen's suggestion that some CAs who use email
On Mon, Mar 23, 2015 at 3:47 PM, Richard Barnes rbar...@mozilla.com wrote:
It has been discovered that an intermediate CA under the CNNIC root has
mis-issued certificates for some Google domains. Full details can be found
in blog posts by Google [0] and Mozilla [1]. We would like to discuss
On Mon, Mar 23, 2015 at 5:50 PM, Kathleen Wilson kwil...@mozilla.com wrote:
Peter, Did you read the blog posts?
1)
https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnic-intermediate-certificate/
2)
On Sun, May 17, 2015 at 5:48 PM, Ryan Sleevi
ryan-mozdevsecpol...@sleevi.com wrote:
On Sun, May 17, 2015 3:28 pm, Peter Bowen wrote:
What if Mozilla puts a simple rule in place?
All CAs must either:
- Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a
assessor who meets
On Sun, May 17, 2015 at 7:59 PM, Ryan Sleevi
ryan-mozdevsecpol...@sleevi.com wrote:
On Sun, May 17, 2015 6:06 pm, Peter Bowen wrote:
I was assuming this discussion was based on the concept that
Government CAs did not need to meet all the audit criteria. Otherwise
why are we having
On Thu, May 14, 2015 at 8:25 AM, Gervase Markham g...@mozilla.org wrote:
The topic of name-constraining government CAs, probably to the TLD(s) of
their territory(ies), has come up numerous times. I'd like to try and
hash out, once and for all, whether we think this is actually a good
idea, so
On Fri, Jun 12, 2015 at 3:46 PM, Tom Ritter t...@ritter.vg wrote:
Are https://technet.microsoft.com/en-us/library/cc751157.aspx and
http://aka.ms/auditreqs the MSFT components (previously?) under NDA?
The published requirements are not under NDA. Microsoft released a
draft version under NDA
The Mozilla CA Certificate policy says that all certificates which are
capable of being used to issue new certificates must either be
technically constrained or be publicly disclosed and audited.
For certificates in the latter category, there are several requirements.
I'm hoping to get clarity
On Sun, May 31, 2015 at 3:43 PM, Ryan Sleevi
ryan-mozdevsecpol...@sleevi.com wrote:
On Sat, May 30, 2015 2:47 pm, Brian Smith wrote:
IIRC, in the past, we've seen CAs that lapse in compliance with Mozilla's
CA policies and that have claimed they cannot do the work to become
compliant again
Thinking about this from a technical perspective, rather than a
political one, this seems very similar to a user deciding to add
additional certificates to their trust store. I think the primary
differences are the need to add a set of certificates and possibly
automatically update the list.
If
On Wed, Nov 11, 2015 at 12:21 AM, Adriano Santoni
wrote:
> The issue I raised is not whether ccTLD are allowed in the BRs (they
> apparently are, to date) or what kind of entity could be allowed a ccTLD in
> their SubCA certificate's permittedSubtrees.
>
> My point
On Wed, Nov 11, 2015 at 3:11 AM, Gervase Markham wrote:
> "Presence on the ICANN section of the list" gets closer, but this
> doesn't solve the brand-TLD problem.
>
> Ideally, we would know which TLDs were public-registration and which
> were not; ICANN has made noises about
> On Oct 8, 2015, at 6:27 AM, Peter Kurrasch wrote:
>
> I will cop to being confused about the Linux situation--I thought some issue
> had been identified for one of the distros.
>
> 1. Impacts to specific products: I had hoped that by now we'd be able to
> point to
On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling wrote:
> I would also like to get clarification on if/when the underscore character
> may be used in each of the name types. Your report seems to flag
> underscores as always prohibited (I think), but I expect that some CAs
On Tue, Nov 17, 2015 at 2:40 PM, Rob Stradling wrote:
> On 17/11/15 17:54, Kurt Roeckx wrote:
>>
>> On Tue, Nov 17, 2015 at 05:40:28PM +, Rob Stradling wrote:
>>>
>>>
>>> Great. I tried importing the list into postgres but I couldn't persuade
>>> it
>>> to accept
er 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 a dNSName i
d, please check it, thanks.
>
> The attached certificate is No. 6653, please check its EKU, thanks.
>
>
> Best Regards,
>
> Richard
>
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Wednesday, November 18, 2015 12:33 AM
> To:
On Wed, Nov 18, 2015 at 10:25 AM, Ryan Sleevi
<ryan-mozdevsecpol...@sleevi.com> wrote:
> On Wed, November 18, 2015 8:56 am, Peter Bowen wrote:
>> On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling <rob.stradl...@comodo.com>
>> wrote:
>> > I would also
On Tue, Sep 8, 2015 at 11:04 AM, Kurt Roeckx wrote:
> On Tue, Sep 08, 2015 at 10:58:39AM -0700, Kathleen Wilson wrote:
>> 28. Remove Code Signing trust bits. As of Firefox 38, add-ons are signed
>> using Mozilla's own roots. There doesn't appear to be anyone else using the
>>
On Thu, Sep 10, 2015 at 3:54 PM, Peter Kurrasch wrote:
> It seems to me that the benefits of this proposed change are minimal while
> the negative impacts to embedded systems are significant. Perhaps I've
> missed something?
>
> It should be understood that code signing is
Sebastien,
I apologize, but I don’t follow the issue. What flaw are you reporting? Can
you describe in detail the problem?
Also, if you think that this is not a publicly known issue, please see
https://www.mozilla.org/en-US/security/#For_Developers
> On Sep 17, 2015, at 8:29 PM, AnilG wrote:
>
> On Friday, 18 September 2015 12:29:46 UTC+10, Peter Gutmann wrote:
>> base. If you look at Mozilla's own figures at
>> https://input.mozilla.org/en-US/, they have a 90% dissatisfaction rating from
>
> To make my point
On Wed, Dec 9, 2015 at 9:35 AM, Matthias Hunstock <no-s...@ple4se.org> wrote:
> Am 17.11.2015 um 09:04 schrieb Peter Bowen:
>
>> There are a couple of rules that may create false positives, so please
>> don't assume every certificate on the sheet is problematic.
>
> I
On Thu, Dec 3, 2015 at 11:17 AM, Kathleen Wilson <kwil...@mozilla.com> wrote:
> On 12/3/15 11:04 AM, Peter Bowen wrote:
>>
>> On Thu, Dec 3, 2015 at 10:31 AM, Kathleen Wilson <kwil...@mozilla.com>
>> wrote:
>>>>
>>>> On 23/11/15 15:57, Pe
On Thu, Dec 3, 2015 at 10:31 AM, Kathleen Wilson <kwil...@mozilla.com> wrote:
>> On 23/11/15 15:57, Peter Bowen wrote:
>>>
>>> I realize that Mozilla carved out allowance for not disclosing, but
>>> the CA/Browser Forum did not adopt this, instead only ex
On Thu, Dec 10, 2015 at 6:07 AM, Matthias Hunstock <no-s...@ple4se.org> wrote:
> Am 09.12.2015 um 18:46 schrieb Peter Bowen:
>
>> Do you have an example where you think IPv6 addresses are not being
>> handled correctly?
>
> Serial 19D70E1B381579 in your document
On Thu, Jan 7, 2016 at 2:34 PM, David E. Ross <nobody@nowhere.invalid> wrote:
> On 1/7/2016 12:29 PM, Kathleen Wilson wrote:
>> On 1/7/16 11:15 AM, Peter Bowen wrote:
>>>
>>>
>>> Until such time that the provide this, I don't see how they are any
>&g
On Wed, Nov 18, 2015 at 5:43 PM, Brian Smith <br...@briansmith.org> wrote:
> Peter Bowen <pzbo...@gmail.com> wrote:
>>
>> 2) For commonName attributes in subject DNs, clarify that they can only
>> contain:
>>
>> - IPv4 address in dotted-decimal notat
On Fri, Nov 20, 2015 at 9:28 AM, wrote:
> Yes, thanks. I had CommonName field in mind and that is limited to 64
> characters but SubjectAltName is completely different when it comes to max
> length (even though they both hold a FQDN).
I had missed that limitation
On Tue, Nov 3, 2015 at 4:24 PM, Kathleen Wilson wrote:
> Topic to discuss [1]:
> “(D3) Make the timeline clear about when the audit statements and disclosure
> has to happen for new audited/disclosed subCAs.
>
> Section 10 of the Inclusion Policy says:
>
On Thu, Nov 19, 2015 at 4:26 PM, Brian Smith <br...@briansmith.org> wrote:
> Peter Bowen <pzbo...@gmail.com> wrote:
>>
>> Robin Alden <ro...@comodo.com> wrote:
>> Given that it doesn't, but that that the BRs say "MUST be either a
>>
On Thu, Nov 19, 2015 at 11:57 AM, Robin Alden wrote:
> Peter said..
>> While I realize that it is not clear cut in many contexts, RFC 5280 is
>> rather clear cut. The authors clearly wanted to avoid stumbling and
>> being eaten by a grue, so they wrote:
>>
>>When the
On Tue, Nov 3, 2015 at 4:24 PM, Kathleen Wilson wrote:
> Topic to discuss [1]:
> “(D3) Make the timeline clear about when the audit statements and disclosure
> has to happen for new audited/disclosed subCAs.
>
> What further clarification needs to be added to Mozilla’s CA
On Tue, May 31, 2016 at 9:59 AM, Nick Lamb wrote:
> That said, so far as I understand the Mozilla requirement is actually that
> such intermediates be disclosed _and audited_. The present disclosure from
> Symantec asserts that this intermediate is covered by the same
I think there are two things getting conflated here:
1) Disclosure of revoked unexpired CA certificates signed by a trusted CA
2) Disclosure of CA certificates signed by CAs that are the subject of #1
Imagine the following heirarchy:
Univercert Root CA (in trust store) --(CA Cert A)-->
On Wed, Jun 22, 2016 at 11:19 AM, Ryan Sleevi wrote:
> On Wed, Jun 22, 2016 at 8:21 AM, Ben Wilson wrote:
>> It seems to me that requiring the registration of these subordinate CAs
>> bloats the Salesforce database unnecessarily.
>
> We've historically
On Sat, Jun 25, 2016 at 3:50 AM, Ben Laurie wrote:
> On 25 June 2016 at 00:56, Rob Stradling wrote:
>> On 24/06/16 14:38, Rob Stradling wrote:
>>>
>>> I've just updated https://crt.sh/mozilla-disclosures.
>>>
>>> There's now a separate grouping for
The Mozilla CA Certificate policy says, in part:
"8. All certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a
certificate included in Mozilla’s CA Certificate Program, MUST be
operated in accordance with Mozilla’s CA Certificate
On Tue, Feb 9, 2016 at 6:55 AM, Erwann Abalea wrote:
> Le lundi 8 février 2016 21:43:19 UTC+1, Kathleen Wilson a écrit :
>> On 2/8/16 12:22 PM, Kathleen Wilson wrote:
>>
>> One topic currently under discussion in Bug #1201423 is regarding root
>> certificates with serial number
On Mon, Feb 8, 2016 at 2:46 PM, Kathleen Wilson wrote:
>
> Note that I think there are still some things with the certlint tests that
> need to be ironed out, before filing bugs for every reported error.
I am unaware of anything that is flagged as Fatal or Error on non-CA
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 Symantec
https://crt.sh/?id=12456194=cablint
https://crt.sh/?id=12434313=cablint
Peter,
I obviously do not represent ComSign, but several of the items in your list
are not really specific to the CPS and instead are more comments on the
Mozilla policies.
On Fri, Jan 29, 2016 at 4:24 PM, Peter Kurrasch wrote:
> * There is a BR from CABF that covers code
On Wed, Mar 9, 2016 at 12:40 PM, Jakob Bohm wrote:
> 1. Use a non-CA OCSP certificate if the relevant clients are known to
> support this aspect of the OCSP protocol (I don't know if any OCSP
> clients, historic or otherwise, lack this ability). Such an OCSP
>
Over the last year or so there seems to be a lot of movement in CA
ownership. Would it be worth asking for each root to provide an
indication of company/organization ownership?
For example, NetLock indicates on their website they were acquired by
Docler Holding in 2013. Similarly, TrustWave
On Fri, Mar 25, 2016 at 7:33 AM, wrote:
> can someone explain to a non security expert, why A-Trust is still not in the
> inclusion phase? This bug-report goes over a year now. Is A-Trust not
> cooperating promptly and correctly? Is Mozilla working too slow? I really
> don't
I'm a little confused about the expected scope of audit reports with
respect to non-Root issuers.
The Mozilla CA policy says:
"The term 'subordinate CA' below refers to any organization or legal
entity that is in possession or control of a certificate that is
capable of being used to issue new
It does to a certain extent. If I have a certificate that uses a
512-bit RSA key and is signed using RSAwithMD2, will Mozilla even
attempt to use that certificate for client authentication?
On Wed, Apr 27, 2016 at 10:54 AM, Richard Barnes wrote:
> For client certificates,
Here is a Google Spreadsheet without the subordinates that have EKU
restrictions. I didn't match to SalesForce, so most of these are
probably already in there.
https://docs.google.com/spreadsheets/d/14lO33nW-tTN86Vq_urmI6IAIWRPZgd1KKfzvrLk5TZQ/edit?usp=sharing
On Wed, Apr 27, 2016 at 6:11 PM,
On Wed, Apr 27, 2016 at 7:36 PM, Richard Barnes <rbar...@mozilla.com> wrote:
> On Wed, Apr 27, 2016 at 8:41 PM, Peter Bowen <pzbo...@gmail.com> wrote:
>>
>> As far as I can tell, SalesForce does not have a way to show multiple
>> certificates for one CA. So it is
On Fri, Apr 29, 2016 at 7:17 PM, Matt Palmer <mpal...@hezmatt.org> wrote:
> On Fri, Apr 29, 2016 at 05:12:28PM -0700, Peter Bowen wrote:
>> On Fri, Apr 29, 2016 at 5:03 PM, Matt Palmer <mpal...@hezmatt.org> wrote:
>> > Even more fun: what if the seria
[ Disclaimer: This message is my personal view and does not
necessarily represent that of my employer. ]
On Thu, May 19, 2016 at 9:15 AM, wrote:
> This has been a very surprising discussion to me. If most CAs were asked “Do
> you think CAs are supposed to investigate
[ Disclaimer: This message is my personal view and does not
necessarily represent that of my employer. ]
On Fri, May 20, 2016 at 5:41 PM, wrote:
> Peter -- the reference to BR 9.6.8(8) is interesting, but is not really
> relevant to discussion of the requirements of BR
On Mon, May 16, 2016 at 6:06 AM, Rob Stradling <rob.stradl...@comodo.com> wrote:
> On 16/05/16 01:43, Peter Bowen wrote:
>
> This discussion should consider what's best for Mozilla's users. Perhaps
> that aligns precisely with the minimum requirements in the EVGs, or perhaps
>
(Top posting to bring the questions to the top)
> 1) What does "Certificate misuse, or other types of fraud" in the definition
> of Certificate Problem Report actually mean?
> 2) What does "misused" mean in Section 4.9.1.1?
I think there are a several of different things that could fall within
On Wed, May 18, 2016 at 7:16 AM, Gervase Markham wrote:
> I think the bullet as a whole could mean that we reserve the right to
> not include CAs who happily issue certs to "www.paypalpayments.com" to
> just anyone without any checks or High Risk string list or anything.
> Such
> On May 5, 2016, at 6:50 AM, Richard Barnes <rbar...@mozilla.com> wrote:
>
> On Thu, May 5, 2016 at 8:32 AM, Peter Bowen <pzbo...@gmail.com> wrote:
>>
>> I will disagree. I think the intent is to "prune" the tree
>
>
> Oh, if only it we
On Wed, Apr 13, 2016 at 2:26 PM, Kathleen Wilson wrote:
> All,
>
> I added the following to
> https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
> ~~
> Intermediate certificates are considered to be technically
I think there is confusion over the generic term “Symantec”. There is no issue
for Symantec (the company) to be an affiliate of the USG FPKI and to operate
CAs mutually cross-certified with the USG FPKI. Additionally there is no issue
with Symantec (or anyone else) to operate CAs included in
Andrew,
Thank you for your review of our CP and CPS. Please see our responses inline.
Thanks,
Peter
> On Aug 10, 2016, at 3:12 PM, Andrew R. Whalley wrote:
>
> Here are the notes from my read-through. I commend Amazon for the clarity
> of their CP and CPS.
>
>
https://tools.ietf.org/html/draft-ietf-curdle-pkix-03 needs to move
forward first. It is currently in working group last call.
https://tools.ietf.org/html/rfc8032 is now published, which replaces
I-D.irtf-cfrg-eddsa, so that removes the last dangling reference from
curdle-pkix.
We also need to
On Tue, Jan 31, 2017 at 5:50 AM, Hubert Kario <hka...@redhat.com> wrote:
> On Monday, 30 January 2017 23:48:51 CET Peter Bowen wrote:
>> See notes inline about known cities with numbers in their name.
>>
>> On Mon, Jan 30, 2017 at 10:39 AM, Peter Bowen <pzbo..
A couple of weeks ago, Google announced Google Trust Services
(https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html)
and also announced that they have acquired two roots that are in
Mozilla trust store.
As discussed in this group previously, Mozilla does not have a very
On Tue, Jan 24, 2017 at 8:00 AM, Richard Barnes wrote:
> On Tue, Jan 24, 2017 at 10:48 AM, Gervase Markham wrote:
>>
>> This helpful spreadsheet shows that they were removed in Firefox 47 and
>> 51 respectively:
>>
On Tue, Jan 24, 2017 at 8:05 AM, Gervase Markham <g...@mozilla.org> wrote:
> On 24/01/17 15:48, Peter Bowen wrote:
>> I think it would be completely reasonable for Mozilla to require a
>> commonName in an update to the policy. I thought it was there, but a
>> CA pus
On Mon, Jan 23, 2017 at 3:32 PM, Kathleen Wilson wrote:
> Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only
> apply to end-entity certificates?
>
> If yes, where does it specify that in the document?
>
> This has come up in a few CA requests, due to
While it is very hard to validate the subject content of certificates
outside of DNS names, there are a number of heuristics that may be
useful to trigger a deeper check to ensure that the data is accurate.
A couple of these that I've found useful are:
1) If stateOrProvince or Locality type
On Tue, Jan 24, 2017 at 12:28 AM, Inigo Barreira wrote:
> Yes, I´m also agree. This was also taken into account when writting the ETSI
> standards, and for the CA certs, the minumun is what Peter has indicated
> plus the common name. We indicate that "... shall contain at
> On Jan 18, 2017, at 7:18 AM, Gervase Markham wrote:
>
> On 17/01/17 23:33, Jakob Bohm wrote:
>> How about "_and versions and strong (>= 256 bits) hashes_",
>
> Do people think we need to go this far?
>
> If we do, we'll need them to specify filenames, not just document
>
On Fri, Sep 2, 2016 at 12:37 AM, Richard Wang wrote:
> We finished the CT posting, all 2015 issued SSL certificate is posted to
> WoSign CT log server: https://ctlog.wosign.com, total 101,410 certificates.
Richard,
Based on CT logs, I have seen certificates from the CAs
(forgot the list)
On Fri, Sep 2, 2016 at 7:55 AM, Peter Bowen <pzbo...@gmail.com> wrote:
> On Fri, Sep 2, 2016 at 12:37 AM, Richard Wang <rich...@wosign.com> wrote:
>> We finished the CT posting, all 2015 issued SSL certificate is posted to
>> WoSign CT log serve
On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang <rich...@wosign.com> wrote:
> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>
> On 2 Sep 2016, at 22:55, Peter Bowen <pzbo...@gmail.com> wrote:
>> Based on CT logs, I have seen certificates from the CAs below, a
On Fri, Sep 2, 2016 at 5:04 PM, Richard Wang wrote:
> From the screenshot, we know why Percy hate WoSign so deeply, we know he
> represent which CA, everything is clear now.
Richard,
With all due respect, many of the people who participate in this
dev-security-policy group
, Richard Wang <rich...@wosign.com> wrote:
> We will check this tomorrow.
> Now our time is 23:32 at night.
>
>
> Regards,
>
> Richard
>
>> On 2 Sep 2016, at 23:20, Peter Bowen <pzbo...@gmail.com> wrote:
>>
>>> On Fri, Sep 2, 2016 at 8:11 AM, Richar
On Wed, Aug 24, 2016 at 6:08 AM, Gervase Markham wrote:
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these
> incidents. This email sets out our understanding of the situation.
>
>
hanks,
>
> Regards,
>
> Richard
>
>> On 4 Sep 2016, at 12:12, Matt Palmer <mpal...@hezmatt.org> wrote:
>>
>>> On Sat, Sep 03, 2016 at 02:18:44PM -0700, Peter Bowen wrote:
>>> Can you also please check the following two certificates? It looks
>
On Thu, Sep 1, 2016 at 9:00 AM, Ryan Sleevi wrote:
> On Wed, August 31, 2016 10:09 pm, Richard Wang wrote:
>> Thanks for your so detail instruction.
>> Yes, we are improved. The two case is happened in 2015 and the mis-issued
>> certificate period is only 5 months that we
In reviewing the Certificate Transparency logs, I noticed the StartCom
has issued multiple certificates with identical serial numbers and
identical issuer names.
https://crt.sh/?serial=14DCA8 (2014-12-07)
https://crt.sh/?serial=04FF5D653668DB (2015-01-05)
https://crt.sh/?serial=052D14BA553ED0
1 - 100 of 314 matches
Mail list logo