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 sho
> 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 th
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 a
> 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
_
From: 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
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
https://www.mail-archive.com/dev-security-poli
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 li
ents for 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?
>
> __
qpnU9FBQAJ
On Thu, Oct 1, 2020 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.
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
H
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
omply.
(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
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
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 mai
and
"If the 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
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 beca
e critical:
Certificate 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
> 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 certificate
:18 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
Is there 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
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 CAs,
ng releases 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
.mail-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.mo
L" 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-
"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 privat
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 intermedi
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 incon
51390
> [3]
> https://groups.google.com/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
Please could 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 wha
SHA256 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
>
> - Cu
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 OC
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
e relaxed,
not the entirety of RFC5280?
- I would also like to see BR 4.9.10 revised to say 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
respon
> -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: D
gt;> when presented, e.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-poli
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,
the issuing 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 Stradli
rent's audit report, 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.
>
&g
>
> 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 mes
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 +, Rob Stradling via
>>> dev-security-policy wrote:
tain certificates, 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
>
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
statement 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
who are 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
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
e addressed by changing steps 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(TBSCertifi
OR the internal serial followed
> by the CSRNG bits.
>
>2C: Generate 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
been implied if 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_Participant
to potentially 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-
crt.sh/?caid=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 that is
esentations of the same value, 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
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&#
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
> inter
s 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
quot;"
> On Thu, Dec 27, 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
&g
legitimate X.509
> objects. Also, I really don't *want* this to be an X.509-only thing, and
> 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),
On 18/12/2018 16:41, Ryan Sleevi wrote:
> On Tue, Dec 18, 2018 at 7:41 AM Rob Stradling wrote:
> On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:
>
> > I think it;s worth calling out that Let's Encrypt has implemented
> what
> &g
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
Seni
f characters.
Note the x509lint warning "explicitText is not using a UTF8String"
though, which stems from RFC5280 forbidding the use of BMPString in this
context:
"Conforming CAs SHOULD use the
UTF8String encoding for e
52 Erlangen
> 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 ne
ages 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
gt; them to take 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_d
.com/) 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
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
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
d) be the enemy of the
good and reasonable.
FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever
signed.
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
___
dev-security-policy mailing
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
these
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
ns/CACommResponsesOnlyReport?CommunicationId=a051J3rMGLL&QuestionId=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...@c
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
y -
https://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
s site, how can 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: mozil
A's applying 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
&
Increasing 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 1
-MM-DD" to the URL to view linting info on older
certs issued by that CA.
e.g., https://crt.sh/?caid=31477&opt=cablint&minNotBefore=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-s
Actalis,
-Â 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-securit
ranted by other vendors (e.g. Apple's exclusion of a host of
> mismanaged Symantec sub-CAs now 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
> i
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
report back once this has completed.
[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&opt=cablint
Note: This is the CT precertificate.
Note 2: According to crt.sh, the OCSP response for this precertificat
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 193 or not.
Best,
-- Simone
--
Rob Stradling
Se
__
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062&d=p8zZ2rF2lZEEgQKoVUUviom_gMvUa93578dYFlK0UQ&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
_
ificates. However, it is 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@lis
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
n 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
Offi
e for
this...
https://crt.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
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
sts.mozilla.org
<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
1 - 100 of 458 matches
Mail list logo
