On 9th July 2019, Kathleen wrote:
> I propose that to handle this situation, the CA may enter the
subordinate CA's current audit statements and use the Public Comment
field to indicate that the new certificate will be included in the next
audit statements.
Hi Kathleen. CCADB now automatically
> We already have automation for CCADB. CAs can and do use it for disclosure of
> intermediates.
Any CA representatives that are surprised by this statement might want to go
and read the "CCADB Release Notes" (click the hyperlink when you login to the
CCADB). That's the only place I've seen
Hi Ben.
> *A CA technically capable of issuing server certificates MUST ensure that
> the CCADB field "Full CRL Issued By This CA" contains either the URL for
> the full and complete CRL or the URL for the JSON file containing all URLs
> for CRLs that when combined are the equivalent of the full
> Perhaps add: "And also include any other certificates sharing the same
> private/public key pairs as certificates already included in the
> requirements." (this covers the situation you mentioned where a
> self-signed certificate shares the key pair of a certificate that chains
> to an included
: Dimitris Zacharopoulos
Sent: 16 October 2020 12:48
To: Rob Stradling ; Ben Wilson ;
mozilla-dev-security-policy
Subject: Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy
Constraints
CAUTION: This email originated from outside of the organization. Do not click
lin
Jakob wrote:
> The part needing clarification started with:
>
> > In addition to the questions posted by Wayne, I think it'd be useful
> > to confirm:
> > ...
I did not address that part of Ryan's post, but Tim's delayed message did
address it.
See
Hi Ben. I agree with Dimitris that the proposed language is a bit confusing.
> "(i.e. a subordinate CA under an EV-enabled root that contains no EKU or the
> id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and a certificatePolicies
> extension that asserts the CABF EV OID of 2.23.140.1.1, the
> ...clarification of what meaning was intended.
Merely this...
"Hi Ryan. Tim Callan posted a reply to your questions last week, but his
message has not yet appeared on the list. Is it stuck in a moderation queue?"
___
dev-security-policy mailing
each level of
message quoting, so as to not misattribute text.
On 2020-10-12 10:43, Rob Stradling wrote:
> Hi Ryan. Tim Callan posted a reply to your questions last week, but his
> message has not yet appeared on the list. Is it stuck in a moderation queue?
>
> _
0 at 4:55 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> As announced previously by Rob Stradling, there is an agreement for
> private investment firm GI Partners, out of San Francisco, CA, to acquire
> Sectigo. Press release:
> https://s
of control?
Thanks,
Wayne
On Thu, Oct 1, 2020 at 1:55 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> As announced previously by Rob Stradling, there is an agreement for
> private investment firm GI Partners, out of San Francisco, CA, to acqui
Hi Doug. I didn't filter by any CRL fields, as per option (2) in my original
post.
From: Doug Beattie
Sent: Wednesday, September 30, 2020 17:53
To: Rob Stradling
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Mandatory reasonCode analysis
Hi Rob
sis I had anyway - that any CRLs and OCSP published after
9-30 had to have reasonCode.
-Original Message-
From: dev-security-policy On
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: dev-security-policy@lists.mozilla.org
Subject: Mandato
.
(I'd be interested to hear folks' opinions on this).
This gist contains my crt.sh query, the results as .tsv, and a .zip containing
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f
--
Rob Stradling
Senior Research & Development Scientist
Emai
This transaction is expected to be finalized during Q4 2020, but presumably the
public discussion envisaged by
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership
could occur earlier than that.
--
Rob Stradling
Senior Research
On 06/07/2020 12:47, Rob Stradling via dev-security-policy wrote:
On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote:
IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling
On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote:
IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling made an indirect reference in
https://groups.google.com/d/msg
to provide this
assurance (for up-to-date clients anyway), although I'd be surprised if
any of the affected CAs would prefer to go that route!
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing
Subordinate CA Private Key is used for signing OCSP responses,
then the digitalSignature bit MUST be set"
...but this is obviously intended to refer to OCSP responses signed
directly by the CA (rather than OCSP responses signed by a CA that also
masquerades as a delegated OCSP res
Doug,
BR 4.9.9 says:
"...the OCSP signing Certificate MUST contain an extension of type
id-pkix-ocsp-nocheck, as defined by RFC6960."
The certificates that Ryan has identified are OCSP signing Certificates,
because they contain the id-kp-OCSPSigning EKU. However, they have been
misissued
ate Sign, CRL Sign
X509v3 Extended Key Usage:
Time Stamping, OCSP Signing
Peter
On Thu, Jul 2, 2020 at 12:14 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > This batch is NOT comprehensive. According to crt.sh, there are
> approximately
> This batch is NOT comprehensive. According to crt.sh, there are approximately
> 293 certificates that meet the criteria of "issued by a Mozilla-trusted,
> TLS-capable CA, with the OCSPSigning EKU, and without pkix-nocheck".
> misissued.com had some issues with parsing some of these
here a way to filter out the revoked and non-TLS/SMIME ICAs?
-Original Message-
From: dev-security-policy
mailto:dev-security-policy-boun...@lists.mozilla.org>>
On Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, June 17, 2020 5:07 AM
To: dev-security-policy
ma
Inspired by last month's email threads and Bugzilla issues relating to CA
Issuers misconfigurations, I've just finished adding a new feature to crt.sh...
https://crt.sh/ca-issuers
Sadly, this highlights plenty of misconfigurations and other problems: PEM
instead of DER, certs for the wrong
and other major project updates in the future:
https://groups.google.com/forum/#!forum/zlint-announcements.
Thanks,
Zakir
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-po
-archive.com/dev-security-policy@lists.mozilla.org/msg10060.html
- Matt
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla
API URL" field to the CCADB?
From: Corey Bonnell
Sent: Monday, March 02, 2020 21:38
To: Rob Stradling; Nick Lamb; mozilla-dev-security-policy
Cc: Matt Palmer
Subject: RE: Acceptable forms of evidence for key compromise
Using ACME as the revocation reporting mechanism
"but ISTM that you've stopped slightly short of actually proposing it in this
list thread. "
Or not!
From: dev-security-policy on
behalf of Rob Stradling via dev-security-policy
Sent: 02 March 2020 21:30
To: Nick Lamb ; mozilla-dev-secur
"I do think there's value in developing some standard mechanism to request
revocation/demonstrate possession of the private key."
Such as https://tools.ietf.org/html/rfc8555#section-7.6 ?
ISTM that any CA could stand up a standalone "revokeCert" API that only accepts
proofs signed by the
Dimitris,
Since CAs should already be disclosing that an intermediate certificate is
"externally-operated" by populating the "Subordinate CA Owner" field in the
CCADB record, what's the benefit of duplicating this information in the
intermediate certificate itself?
What happens if an
On 02/10/2019 00:51, Wayne Thayer wrote:
> On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote:
>
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case
> that the BRs are inconsiste
/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/R0gr1d6wBQAJ
[4]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
ould I
ask you to take this discussion there?
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 16/09/2019 18:08, Andrew Ayer wrote:
> On Fri, 13 Sep 2019 08:22:21 +
> Rob Stradling via dev-security-policy
> wrote:
>
>> Thinking aloud...
>> Does anything need to be clarified in 6962-bis though?
>
> Yes, it's long past time that we clarified what thi
6 for the
> issuerNameHash and issuerKeyHash.
>
> Supporting info
> RFC 6960: https://tools.ietf.org/html/rfc6960
> - 4.1.1. ASN.1 Specification of the OCSP Request
> RFC 2560: https://tools.ietf.org/html/rfc2560
> - 4.1.1 Request Syntax
>
> - Curt
-
On 17/09/2019 08:01, Kurt Roeckx via dev-security-policy wrote:
> On 2019-09-16 14:02, Rob Stradling wrote:
>>
>> ISTM that this "certificate presumed to exist" concept doesn't play
>> nicely with the current wording of BR 4.9.10:
>> 'If the OCSP re
On 16/09/2019 23:58, Wayne Thayer wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote:
> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in
> question:
> (1) MUST respond
something roughly
along these lines:
'If the OCSP responder receives a status request for a serial number
that has not been allocated by the CA, then the responder SHOULD NOT
respond with a "good" status.'
P.S. Full disclosure: Sectigo currently provides an (unsigned)
; -Tim
>
>> -Original Message-----
>> From: Rob Stradling
>> Sent: Friday, September 13, 2019 4:22 AM
>> To: Tim Hollebeek ; Jeremy Rowley
>> ; Alex Cohn
>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
>>
>> Subject: Re: DigiCe
.g., with https://crt.sh/?id=1868433277?
>>
>> Alex
>> _______
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>>
On 29/07/2019 21:52, Andrew Ayer via dev-security-policy wrote:
> On Wed, 24 Jul 2019 16:41:53 +
> Rob Stradling via dev-security-policy
> wrote:
>
>> [Wearing crt.sh hat]
>>
>> https://crt.sh/mozilla-disclosures now has two new buckets:
>> - Disclosed,
g CA under their own
> qualifying audit, and our audits which cover the Root and the intermediate CA
> which we operate in an offline manner.
>
> Thank you,
> Brenda Bernal
> DigiCert
>
> On 7/24/19, 9:42 AM, "dev-security-policy on behalf of Rob Stradling via
&g
so
> this too looks like an incorrect disclosure.
>
> Regarding Sectigo and Web.com, although their CPSes use extremely
> similar language, they are not consistent, since they list different
> CAA domains.
>
> Regards,
> Andrew
> This second batch of notifications went out to the respective CAs at
> approximately 10:30AM Eastern time today (April 3, 2019)
>
>
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited
This message
On 18/03/2019 21:11, Hector Martin 'marcan' wrote:
> On 19/03/2019 02.17, Rob Stradling via dev-security-policy wrote:
>> On 18/03/2019 17:05, Kurt Roeckx wrote:
>>> On Mon, Mar 18, 2019 at 03:30:37PM +0000, Rob Stradling via
>>> dev-security-policy wrote:
>>
icates, as listed on crt.sh.
> And after some amount of time, we'll notify the CAs to indicate key
> compromise. The reason for this delay would be to not blind-side site
> owners.
>
> On the other hand, given that the private keys have *already* been
> compromised (by wa
On 18/03/2019 17:05, Kurt Roeckx wrote:
> On Mon, Mar 18, 2019 at 03:30:37PM +0000, Rob Stradling via
> dev-security-policy wrote:
>>
>> When a value in column E is 100%, this is pretty solid evidence of
>> noncompliance with BR 7.1.
>> When the values in column E a
On 18/03/2019 15:43, Rob Stradling via dev-security-policy wrote:
> On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote:
>
>> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
>>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote:
> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
>
>>> If any other CA wants to check theirs before someone else does, th
On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
>> If any other CA wants to check theirs before someone else does, then now is
>> surely the time to speak up.
>
> Someone else is in th
ment from Sectigo at [2].
[1]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#23-baseline-requirements-conformance
[2]
https://sectigo.com/blog/all-sectigo-public-certificates-meet-64-bit-serial-number-requirements
--
Rob Stradling
Senior Research &
re add a prefix to ensure
> it is positive, and even those are not providing it unless they have lots of
> serial numbers with a big block of zeros.
>
> If any other CA wants to check theirs before someone else does, then now is
> surely the time to speak up.
Someone else is in the
On 13/03/2019 03:04, Peter Gutmann wrote:
> Rob Stradling via dev-security-policy
> writes:
>
>> I've been working on an alternative proposal for a serial number generation
>> scheme, for which I intend to write an I-D and propose to the LAMPS WG.
>
> This seems
teps 7 and 8 to...
7. Perform a binary search for the first occurrence of H || A || R || D
in the DER(TBSCertificate) that was produced in step 6, and replace that
first occurrence with H || A || R || TRUNCATE_TO_64BITS(D).
8. Sign the (modified by step 7) DER(TBSCertificate).
> On Tue, Mar
104 to 152 CSRNG bits. Choose a random prefix byte
> between 0x01 and 0x7F, then check if the concatenation collides with
> a previously issued serial number. If so, change the random prefix
> byte until an unused serial number is found, if all 127 prefix bytes
> r
f he'd omitted it.
I'd also like to remind everyone about the Mozilla Forum Etiquette [2]
Ground Rules, especially "Be civil" and "Be kind to newcomers".
[1] https://wiki.mozilla.org/CA/Policy_Participants
[2] https://www.mozill
tentially share this on the
> list, I am attaching a copy of that letter to this post.
>
> Regards,
>
>
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-secur
id=22507.
[1] https://www.quovadisglobal.com/QVRepository/ExternalCAs.aspx
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 24/01/2019 14:09, Kurt Roeckx via dev-security-policy wrote:
> On 2019-01-24 12:08, Rob Stradling wrote:
>>
>> Hi Kurt.
>>
>> BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
>> address or Fully-Qualified Domain Name
alue, but
they are not the same value).
This issue is one of the things that CABForum ballot 202 sought to
clarify, and IIRC it was actually the reason why ballot 202 failed.
> And if
> you create a commonName then, you are required to check that it matches
> the xn--gau-7ka.sie
On 14/01/2019 08:09, westmail24--- via dev-security-policy wrote:
> This URL ( https://crt.sh/test-websites ) does not work (~5 days)
Fixed. Thanks.
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security
On 02/01/2019 14:10, Rob Stradling via dev-security-policy wrote:
> On 02/01/2019 13:44, info--- via dev-security-policy wrote:
>> We're reviewing what happened with this subCA, because it's reported to the
>> CCADB (like all other subCAs). At the moment we've seen tha
ion to the CCADB?
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 02/01/2019 13:44, info--- via dev-security-policy wrote:
> El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling escribió:
>> On 09/10/2018 23:53, Wayne Thayer wrote:
>>> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:
>>> Wayne, Kathleen
On 09/10/2018 23:53, Wayne Thayer wrote:
> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:
> Wayne, Kathleen:
> Given the number of times that all the CAs in Mozilla's Root Program
> have been reminded about Mozilla's requirements for disclosing
> intermediate ce
ments in ASN.1 specifications are meaningless
or that they do not convey intent?
Also, are you suggesting that a canonical OID name must clearly convey
the full and precise intent of the purpose(s) for which the OID should
be used?
--
Rob Stradling
Senior Research & Deve
2018 at 05:56:08PM +0900, Hector Martin 'marcan' via
> dev-security-policy wrote:
>> On 19/12/2018 20:09, Rob Stradling via dev-security-policy wrote:
>>> I'm wondering how I might add a pwnedkeys check to crt.sh. I think I'd
>>> prefer to have a table of SHA-256(SPKI) stor
; this way I could annoy people who don't like JOSE as well as the people who
> don't like X.509.
>
> With regards to using Trillian (or verifiable data structures in general),
> given my background in working with CT, you can rest assured I spent a *lot*
> of time pondering how a tra
plemented this same mitigation about a month ago.
> I am also interested to know if other CAs are considering this or other
> mitigations (e.g. multi-perspective validation) for this attack.
Multi-perspective validation is something we've started to think about too.
--
Rob Stradling
Senior Researc
which stems from RFC5280 forbidding the use of BMPString in this
context:
"Conforming CAs SHOULD use the
UTF8String encoding for explicitText, but MAY use IA5String.
Conforming CAs MUST NOT encode explicitText as VisibleString or
BMPString."
RFC6818 un-forbids it, but
langen
> Phone: +49 (0)9131 - 530 15 85
> Mobile: +49 (0)152 - 228 94 134
> Web: http://www.buschart.de
>
>
> Am Do., 13. Dez. 2018 um 12:18 Uhr schrieb Rob Stradling
> mailto:r...@sectigo.com>>:
>
> Thanks to Kathleen for suggesting/requesting this new crt
using Subscriber Certificates that are (i)
valid, (ii) revoked, and (iii) expired."
[2] https://github.com/crtsh/test_websites_monitor
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-s
e any steps necessary to comply [2].
>
> - Wayne
>
> [1]
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> [2]
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
--
) is the new name for "Comodo CA".
https://sectigo.com/newsroom/comodo-ca-rebrands-as-sectigo
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozi
On 19/10/2018 10:42, Ben Laurie wrote:
> On Fri, 19 Oct 2018 at 10:38, Rob Stradling wrote:
FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever >>>>
signed.>>>
Put it in Trillian? :-)
That had occurred to me. ;-)
Would it be useful?
To be p
On 18/10/2018 22:55, Ben Laurie wrote:
On Fri, 12 Oct 2018 at 19:01, Rob Stradling wrote:
On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
> On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie mailto:b...@google.com>> wrote:
>> This is one of the reaso
uot;
(see also https://bugzilla.mozilla.org/show_bug.cgi?id=1442091)
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.or
requirements are met" failed in this case.
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
municationId=a051J3rMGLL=Q00078,Q00079
[4] https://crt.sh/mozilla-disclosures#undisclosed
[5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
On 01/10/2018 16:51, Rob Stradling via dev-security-policy wrote:
Hi Iñigo.
I suspect it's because my script that produces the 1 week summary data
[1] isn't using a consistent view of the underlying linting results
throughout its processing. Hopefully this [2] will fix it.
Doh. [2
://bugzilla.mozilla.org/show_bug.cgi?id=1495518
* Certinomis: issued & revoked a precertificate containing a SAN of
'www', didn't report it -
https://bugzilla.mozilla.org/show_bug.cgi?id=1495524
- Wayne
On Mon, Oct 1, 2018 at 8:51 AM Rob Stradling via dev-security-policy
<mailto:dev-security
Comodo have more certs with errors (15030) than
certs issued (15020).
Regards
From: dev-security-policy on behalf
of Adriano Santoni via dev-security-policy
Sent: Monday, October 01, 2018 10:09 PM
To: Rob Stradling; Doug Beattie
Cc: mozilla-dev-security
plying for inclusion, which in some cases are
ones which have a history of non-compliance under other root programs,
but there's no way to programatically tell if a CA is applying for
inclusion).
Alex
On Mon, Oct 1, 2018 at 10:05 AM Rob Stradling via dev-security-policy
<mailto:dev-securi
ing number of Errors found in crt.sh
Thank you Rob!
If I am not mistaken, it seems to me that we have just 1 certificate in that
list, and it's a non-trusted certificate (it was issued by a test CA).
Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
On 01/10/2018 14:38, Adriano S
to view linting info on older
certs issued by that CA.
e.g., https://crt.sh/?caid=31477=cablint=2018-01-01
(This feature is undocumented because not all historical certs have been
linted by crt.sh).
Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
On 01/10/2018 14:38, Adr
- Digicert,
- Microsoft,
-
There are also some warning checks that should actually be errors like
underscores in CNs or SANs.
Doug
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
___
dev-security-policy m
ow under DigiCert's operational control), the
> past precedent (e.g. the gradual distrust of WoSign/StartCom through
> whitelists, of CNNIC through whitelists), and the public discussion
> involved so entirely that it's entirely unfounded.
>
> So I think your continued suggestion that it
On 17/06/18 21:09, Daniel Cater via dev-security-policy wrote:
On Monday, 14 May 2018 15:25:43 UTC+1, Rob Stradling
I'm currently running the check against all of the certs on the crt.sh
DB. I'll report back once this has completed.
Hi Rob,
Did your checks find anything else in the end
[1] https://secure.comodo.com/debian_weak_keys/
--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 16/03/18 10:27, Rob Stradling via dev-security-policy wrote:
On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:
Please see https://crt.sh/?id=353098570=cablint
Note: This is the CT precertificate.
Note 2: According to crt.sh, the OCSP response for this precertificate
a
Validity Period no greater than 825 days.
> Subscriber Certificates issued after 1 July 2016 but prior to 1
March 2018 MUST have a Validity Period no greater than 39 months.
I'd appreciate some hints about whether a certificate issued on March
1st should be considered subject to Ballot
______
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
Bradford, UK
Office: +441274730505
C
suboptimal (in terms of bytes on the wire).
[1] https://github.com/golang/go/issues/21527
--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
http
keypair. Once that new certificate has been
installed, Comodo CA will revoke https://crt.sh/?id=206535041.
Regards,
Rich Smith
Sr. Compliance Manager
Comodo CA
--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-po
safer option - e.g. sign random string+Subject DN.
And also throw in some transparency...
https://mailarchive.ietf.org/arch/msg/trans/WLFmIyaH4BJo77ZJDinKJcylOcg
--
Rob Stradling
Senior Research & Development Scientist
Email: rob.stradl...@comodoca.com
Bradford, UK
Office: +441274730
rt.sh/mozilla-onecrl (which parses the OneCRL JSON feed)
suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467.
--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy
users (see
https://bugzilla.mozilla.org/show_bug.cgi?id=908125)
Jonathan
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
h
ist
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No.
the job of running Mozilla's CA Program between us, so
he will be actively working on both of these Modules.
Thanks,
Kathleen
[1] https://wiki.mozilla.org/Modules
[2] https://wiki.mozilla.org/Modules/All#CA_Certificates
[3] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy
--
Rob
about the Mozilla CA communication that said that CAs had until 15
April 2018?
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Rob Stradling via dev-security-policy
Sent: Tuesday, January 16, 2018 2:29 PM
To: m
1 - 100 of 381 matches
Mail list logo
