On Wednesday, May 17, 2017 at 11:24:54 AM UTC, Gervase Markham wrote:
> Well, such contacts are normally per CA rather than per root. I guess we
> could add it on the CA's entry.
Tbh, I'm not really familiar with your salesforce setup, I was just using this
as a stand-in for "place where CA can b
This request from TrustCor is to include the “TrustCor RootCert CA-1”,
“TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the
Websites and Email trust bits.
TrustCor, located in Canada, is a commercial organization that develops privacy
protection services and issues ce
All,
I will greatly appreciate your help in reviewing and commenting on this root
inclusion request from Certigna.
Thanks,
Aaron
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-
On 17/05/17 15:49, Rob Stradling wrote:
> The "Listed Here Since" timestamps for the 24 intermediates currently in
> this category are set to today, because I don't have a time machine to
> go back and find out how long they've actually been listed in this
> category. ;-)
Lack of time machine is
On 17/05/17 15:21, Gervase Markham via dev-security-policy wrote:
On 17/05/17 15:15, Rob Stradling wrote:
Shall I add the same two fields to
https://crt.sh/mozilla-disclosures#disclosureincomplete as well?
Yes, why not? :-)
Gerv
Done.
The "Listed Here Since" timestamps for the 24 intermedi
On 17/05/17 15:15, Rob Stradling wrote:
> Shall I add the same two fields to
> https://crt.sh/mozilla-disclosures#disclosureincomplete as well?
Yes, why not? :-)
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lis
On 17/05/17 15:12, Gervase Markham via dev-security-policy wrote:
On 17/05/17 13:32, Rob Stradling wrote:
I've just added two columns to
https://crt.sh/mozilla-disclosures#undisclosed:
- "Earliest SCT".
- "Listed Here Since".
Lovely! Now we just need a cert to be on the list so we can se
On 17/05/17 13:32, Rob Stradling wrote:
> I've just added two columns to
> https://crt.sh/mozilla-disclosures#undisclosed:
> - "Earliest SCT".
> - "Listed Here Since".
Lovely! Now we just need a cert to be on the list so we can see what it
looks like ;-)
Gerv
_
On 17/05/17 15:08, Rob Stradling wrote:
> Incidentally, it's true that Mozilla have said that they don't care
> about the Code Signing trust bit any more, but the
> CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug?
Yes, but a low priority one. Feel free to file :-)
Gerv
___
On 17/05/17 12:55, Jakob Bohm wrote:
> That is /human readable/ information, not /computer readable/ data that
> can be imported by other libraries when those are used with the Mozilla
> root program.
Yes, indeed. But you asked where in certdata.txt those things are, and
that page explains pretty
On 17/05/17 14:43, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-17 14:40, Rob Stradling wrote:
On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 19:05, Gervase Markham wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Ti
On 2017-05-17 14:40, Rob Stradling wrote:
On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 19:05, Gervase Markham wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Timestamp) and a "Last Modified
By" field (Username, Timestamp) in
On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 19:05, Gervase Markham wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Timestamp) and a "Last Modified
By" field (Username, Timestamp) in the CCADB, but neither of these
fields are
On 11/05/17 18:05, Gervase Markham via dev-security-policy wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Timestamp) and a "Last Modified
By" field (Username, Timestamp) in the CCADB, but neither of these
fields are currently provided in the public CSV rep
On 17/05/2017 13:29, Gervase Markham wrote:
On 16/05/17 18:04, Jakob Bohm wrote:
Could you please point out where in certdata.txt the following are
expressed, as I couldn't find it in a quick scan:
1. The date restrictions on WoSign-issued certificates.
2. The EV trust bit for some CAs.
I am
On 2017-05-17 13:23, Michael Casadevall wrote:
On 05/17/2017 05:04 AM, Kurt Roeckx wrote:
If the key is compromised, you can't rely on any date information
anymore, you need to revoke it completely and break things.
Won't that only be true in certificates without SCTs? Once you have a
SCT, yo
On 16/05/17 18:04, Jakob Bohm wrote:
> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
>
> 1. The date restrictions on WoSign-issued certificates.
>
> 2. The EV trust bit for some CAs.
I am surprised you are engaging in a dis
On 16/05/17 02:26, userwithuid wrote:
> After skimming the responses and checking a few CAs, I'm starting to
> wonder: Wouldn't it be easier to just add another mandatory field to
> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
> policy and just use that to provide a public l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/17/2017 05:04 AM, Kurt Roeckx wrote:
> If the key is compromised, you can't rely on any date information
> anymore, you need to revoke it completely and break things.
>
Won't that only be true in certificates without SCTs? Once you have a
SC
在 2017年5月17日星期三 UTC+8下午5:18:59，Rob Stradling写道：
> On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote:
> > 在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道：
> >> On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
> >>
> * CPS Appendix1: Certificate information of the pub
On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote:
在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道：
On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh
On 2017-05-16 14:24, Michael Casadevall wrote:
Maybe a bit out there, but an interesting thought none the less. It
would definitely go a good way at preventing one root certificate from
underpinning a large chunk of the internet. My thought here is if a
large "Too Big to Fail" CA's private key wa
22 matches
Mail list logo
