that last item, I understand there is much controversy over
the prevention and remediation of that behavior but I would hope there
is widespread agreement that it does at least exist.
It exists, in the same way that cars are used for bank robbery getaways,
but the Highway Code doesn't men
sible).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phon
lopment practices
("3rd normal form"), perhaps at most one attribute shortname in column
1.
e.g. Your example would be written as:
"OU","N/A"
"ST","N/A"
"L","N/A"
,"."
"O","Internet Widgits Pty Ltd"
nt with wording elsewhere in the
policy for for such things as OCSP signing certificates, CRL signing
certificates, time stamping certificates and other such CA operational
certificate types now known or yet to be invented.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo
t when using
Chrome. These suggestions are meant to provide further guidance about the
set of concerns we discussed, and to illustrate ways in which they can be
meaningfully and objectively addressed, in a way that can be consistently
applied to all CAs.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, W
On 25/04/2017 05:04, Ryan Sleevi wrote:
On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 25/04/2017 03:10, Peter Kurrasch wrote:
Fair enough. I propose the following for consideration:
Prior to transferring owners
y job) there's always room to reconsider policy. But what we need is
a clearly-stated and compelling case that changing the way we think
about these things would have significant and realisable benefits, and
that any downsides are fairly enumerated and balanced against those gains.
Enjoy
On 21/04/2017 21:29, Nick Lamb wrote:
On Tuesday, 18 April 2017 18:33:29 UTC+1, Jakob Bohm wrote:
I believe the point was to check the prospective contents of the
TBSCertificate *before* CT logging (noting that Ryan Sleevi has been
violently insisting that failing to do that shall be punished
On 21/04/2017 00:36, Ryan Sleevi wrote:
On Thu, Apr 20, 2017 at 6:15 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Technically, the part after the @ could also be a bang!path, though
this is rare these days.
No, technically, it could not.
RF
could also be a bang!path, though
this is rare these days.
So maybe some wording in the Mozilla e-mail end cert requirements for
how the phrase "Domain Name" in the TLS cert BRs maps to rfc822-names.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Tran
e holder has lost its rights to the specific
e-mail address under that domain?
This is: https://github.com/mozilla/pkipolicy/issues/14
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discus
ully Jeremy and Ben from DigiCert can comment on this thread (
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2DwAJ
for the archive) with details about the issues and the steps taken.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www
ween additional
processes.
Of course I know nothing of your specific circumstances, this is just a general
observation about how I think I'd approach the question of improving issuance
quality with minimal risk.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
addresses, that authority may
also be divorced from ownership of the maily.net domain.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors
ion, it is also common to provide an authoritative
out-of-band copy of the fingerprint as something relying parties should
check when installing the CA root cert.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +4
27;s root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.
Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
Enjoy
Jakob
--
a's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.
Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
Enjoy
,
Mozilla root program requirements do apply to such certificates and the
roots that are trusted to issue them.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding
manding actions during
that holiday is considered morally deficient at a minimum.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
On 06/04/2017 23:49, Ryan Sleevi wrote:
On Thu, Apr 6, 2017 at 1:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Here are some ideas for reasonable new/enhanced policies (rough
sketches to be discussed and honed before insertion into a future
M
nces it'll be issuing free
MITM SSL certificates starting Monday morning) then Mozilla is still
free to take extraordinary action and distrust Achmed's root immediately
without waiting until Monday morning.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transfo
ind of reach out would be appropriate
from a customer service perspective.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo -
On 04/04/2017 05:30, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
So why does Mozilla want disclosure and not just a blanket X on a form
stating that all SubCAs are adequately audited, follow B
On 04/04/2017 05:03, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I see it as part of the underlying reasoning. Mozilla et al wants
disclosure in order to take action if the disclosed facts are
On 04/04/2017 00:31, Peter Bowen wrote:
On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
wrote:
On 03/04/2017 21:48, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The assumptio
On 03/04/2017 21:48, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The assumptions are:
0. All relevant root programs set similar/identical policies or they
get incorporatated into the CAB/F BR
On 03/04/2017 19:24, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
taking a holiday and not being able to process a disclosure of a new
SubCA.
Considering that the CCADB does not require any of
On 01/04/2017 03:49, Ryan Sleevi wrote:
On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
As previously stated, I think this will be too short if the issuance
happens at a time when a non-CCADB root program (or the
ot;NTT Docomo" audit report is actually either the
very same "Symantec" audit report, or one of the other "Symantec" audit
reports for a relevant period.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.
On 31/03/2017 19:31, tarah.syman...@gmail.com wrote:
On Friday, March 31, 2017 at 9:51:03 AM UTC-7, Jakob Bohm wrote:
Dear Tarah,
Below some friendly speculation as to what the parts that some bloggers
claimed was included (if those claims were somehow true) might have
been (i.e. where *you
an, overlapping the other by 2 days and forcing any
coordinated disclosure to wait the full 28 days.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and
On 30/03/2017 08:08, Gervase Markham wrote:
On 29/03/17 20:42, Jakob Bohm wrote:
That goal would be equally (in fact better) served by new market
entrants getting cross-signed by incumbents, like Let's encrypt did.
Google will be issuing from Google-branded intermediates under t
ly ubiquitous in the
WebPKI, manual checking remains relevant.
On Wed, Mar 29, 2017 at 2:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 29/03/2017 16:47, Gervase Markham wrote:
On 29/03/17 15:35, Peter Kurrasch wrote:
In other words, what used
Google-issued certificate while one would expect the opposite of
anything hosted outside the Alphabet group.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding a
On 28/03/2017 16:13, Ryan Sleevi wrote:
On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
In principle any source of information could change just one minute
later. A domain could be sold, a company could declare bankrup
On 28/03/2017 15:20, Ryan Sleevi wrote:
On Tue, Mar 28, 2017 at 8:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
While this has apparently already passed, the earlier date for
requiring revalidation is going to be a problem for any CA th
mpany registrations etc.), providing little reason to impose the
inconvenience and cost of short certificate lifespans onto every
ongoing business and every personal website on the planet.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, De
recursion, but would not have
given Mozilla sufficient assurance it is using this ability in a policy
compliant manner.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-
mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Jakob Bohm via dev-security-policy
Sent: Monday, March 27, 2017 3:58 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Grace Period for Sub-CA Disclosure
On 27/03/2017 23:41, Rob Stradling wrote:
On 27/0
On 27/03/2017 23:41, Rob Stradling wrote:
On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote:
It should also be made a requirement that the issued SubCA certificate
is provided to the CCADB and other root programs before providing it to
the SubCA owner/operator,
That'd be
sions during the upcoming
Christian Easter holiday (which is also frequently used for scheduled
server downtime).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is no
On 24/03/2017 21:03, Jakob Bohm wrote:
On 24/03/2017 19:08, Ryan Sleevi wrote:
On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Examples discussed in the past year in this group include the Taiwan
GRCA roots and several
On 24/03/2017 19:08, Ryan Sleevi wrote:
On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Examples discussed in the past year in this group include the Taiwan
GRCA roots and several of the SubCAs hosted by Verizon prior
On 24/03/2017 17:12, Peter Bowen wrote:
On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy
wrote:
(Wearing an individual hat)
On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
One common scenario that
A
cannot outsource to a third party would in this case not be allowed to
be "insourced" from the "CA operator" to the nominally responsible
organization.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direc
On 24/03/2017 05:54, Walter Goulet wrote:
On Thursday, March 23, 2017 at 8:13:38 PM UTC-5, Jakob Bohm wrote:
On 23/03/2017 22:59, Walter Goulet wrote:
Hi all,
This is not directly related to Mozilla policy, CA issues or really any of the
normal discussions that I typically see in the group
ch? Note that this requires a pretty
significant mindset change in what it means to test applications/systems, most
notably because of the use of reserved, test-only domains. But I'd be really
interested in what others think.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https:/
On 23/03/2017 20:27, Ryan Sleevi wrote:
On Thu, Mar 23, 2017 at 1:38 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 23/03/2017 17:09, Ryan Sleevi wrote:
(Posting in a Google Capacity)
I just wanted to notify the members of this Forum that w
t their certificate.
The computing world at large would be significantly inconvenienced if
Symantec was forced to close down its CA business, in particular the
parts of that business catering to other markets than general WebPki
certificates.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S
nt-in-time audit.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones an
es in root certificates not to match the current owner, those who are
looking at certificate chains should not be relying on the value in the root
certificate in the first place wrong in very significant situations.
Ryan
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wise
during the
transition and the discussed inapplicability of some wording in the
old Google CP/CPS to the new situation.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non
't display CA names.
At least in one Mozilla-based browser, the UI shows the name of the
Intermediary as a tooltip, not of the root. So OK for this case.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 1
On 08/03/2017 14:18, Ryan Sleevi wrote:
On Wed, Mar 8, 2017 at 1:36 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I am simply going by the wording in Gervs posting not stating what you
stated. I presume that if Gerv wanted to complete eliminate t
On 08/03/2017 06:27, Ryan Sleevi wrote:
On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I saw nothing in Gervs posting suggesting that banning all kinds of
RA/DTP relationships was the intended effect.
But would yo
On 08/03/2017 04:21, Ryan Sleevi wrote:
On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I contradicted you in saying that RAs (or DTP as you now want to call
them) were not supposed to be banned by the policy change.
On 08/03/2017 01:40, Ryan Sleevi wrote:
On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 07/03/2017 21:37, Ryan Sleevi wrote:
To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
Third P
number of similar RAs handle in-person verification steps for a
small geographic area (such as schemes where each city hall handles
checking photo ID of applicants as part of validation at better
than EV level).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transform
ificates remain valid, though no further
such certificates were issued in this interim period.
Similarly could Google and/or GTS issue a dedicaed CP/CPS pair for the
new roots during the brief period where Google (not GTS) had control of
those new roots.
Enjoy
Jakob
--
Jakob Bohm, CIO, Part
On 03/03/2017 06:44, Ryan Sleevi wrote:
Hi Jakob,
On Thu, Mar 2, 2017 at 9:14 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I read his previous answer as saying that the system will in no case
extend the validity of a validation beyond the durat
verify [certificatefile]", which other CAs' revoked and unrevoked
certificates are working fine with.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-b
d with an X, which your server shouldn't send)
NiceCA-via-JoeRA-SSL-Regular-March-2017.cer (PEM format)
X NiceCA-SHA256RSA-Root-2016.cer (PEM format)
NiceCA-SHA256RSA-Root-2016-cross-by-UserFirst.cer (PEM format)
X UserFirst-ancient-root.cer (PEM format)
--- End example ---
En
issued with
the same processing bug and arrange to have any such certificates
similarly fixed.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may cont
a50d383f89f0aa13a6ff2e0894ba5ff
SHA-512:
f39a04842e4b28e04558496beb7cb84654ded9c00b2f873c3ef64f9dfdbc760cd0273b816858ba5b203c0dd71af8b65d6a0c1032e00e48ace0b4705eedcc1bab
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Enjoy
Jakob
--
Jakob Bohm, CIO, Part
On 14/02/2017 22:03, Nick Lamb wrote:
On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote:
Unfortunately, for these not-quite-web-server things (printers, routers
etc.), automating use of the current ACME Let's encrypt protocol with
or without hardcoding the Let's Encrypt UR
27;s Encrypt/ACME or WoSign.
Similarly, it would be useful to have an easily findable tool/script
for doing ACME in a semi-offline way that doesn't presume that the ACME
client has any kind of direct control over the servers that will be
configured with the certificates. Such a tool could b
On 10/02/2017 16:34, Ryan Sleevi wrote:
On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
For clarity, I was pointing out that GTS seems to have chosen a method
likely to fail if an when actually needed, due to the t
On 10/02/2017 05:42, Ryan Sleevi wrote:
On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>> wrote:
Additional issue #2: The information at https://pki.goog/ about how to
report misissuance directs visitors to a g
ature) tends to require reaction
times measured in days/weeks rather than the 1 day maximum specified
in Google's CPS.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is n
On 09/02/2017 18:20, Jakob Bohm wrote:
On 09/02/2017 10:59, Gervase Markham wrote:
On 08/02/17 11:25, Jakob Bohm wrote:
My logic is that adding additional entropy to a serial number whose
length is fully controlled by CA procedures can increase the
mitigations against SHA-1 weaknesses. For
On 09/02/2017 10:59, Gervase Markham wrote:
On 08/02/17 11:25, Jakob Bohm wrote:
My logic is that adding additional entropy to a serial number whose
length is fully controlled by CA procedures can increase the
mitigations against SHA-1 weaknesses. For example if the existing CA
setup uses all
On 08/02/2017 10:55, Gervase Markham wrote:
On 07/02/17 19:15, Jakob Bohm wrote:
Point 2 does not apply if the certificate is an OCSP signing certificate
manually issued directly from a root.
Should be point 1 (on OCSP signing certificate is an EE cert)
Nope, I'm fairly sure I mean po
On 07/02/2017 20:49, David E. Ross wrote:
On 2/7/2017 11:15 AM, Jakob Bohm wrote:
Root certificates previously withdrawn for this purpose are encouraged
to report this fact to Mozilla by and to maintain valid entries in
the CCADB for such roots, all for the benefit of organizations that
es previously withdrawn for this purpose are encouraged
to report this fact to Mozilla by and to maintain valid entries in
the CCADB for such roots, all for the benefit of organizations that
maintain or service software that are or interoperate with such older
software.
Enjoy
Jakob
--
Jako
On 03/02/2017 14:30, Ryan Sleevi wrote:
On Thu, Feb 2, 2017 at 9:37 PM Jakob Bohm wrote:
On 03/02/2017 05:22, Ryan Sleevi wrote:
On Thu, Feb 2, 2017 at 3:59 PM, Jakob Bohm
wrote:
On 02/02/2017 00:46, Kathleen Wilson wrote:
All,
I've added another Potentially Problematic Practic
On 03/02/2017 05:22, Ryan Sleevi wrote:
On Thu, Feb 2, 2017 at 3:59 PM, Jakob Bohm wrote:
On 02/02/2017 00:46, Kathleen Wilson wrote:
All,
I've added another Potentially Problematic Practice, as follows.
https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL
The enc
t follow rule 2, the CA
must publish a list of the exact IssuerDN encodings used in such
certificates.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding
bug.cgi?id=1334377.
The direct attachment link is:
https://bugzilla.mozilla.org/attachment.cgi?id=8831933.
The bug report contains additional documentation supporting our response.
Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner
nd provinces of large countries such as
Australia, Canada, China, and Russia. Thus confusing some form
designers to presume those tables indicate that such listed items are
actual states/provinces.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860
On 30/01/2017 14:24, Peter Gutmann wrote:
Jakob Bohm writes:
Surprised you didn't know that, considering who you are.
Uhh, I did know that, that's why I checked it about 15-odd years ago to see if
anything would notice if it was done wrong (I can't remember the exact date,
it
On 28/01/2017 07:51, Peter Gutmann wrote:
Jakob Bohm writes:
DSA and ECDSA signatures are only secure if the hash algorithm is specified
in the certificate, presumably as part of the AlgorithmIdentifier in the
SubjectPublicKeyInfo.
It's in the (badly-named) signature field of the cer
quot;RSA
PKCS#1 v1.5 with SHA-256"). This is typically done where there is no
security downside to using the same certificate and public key with
different hash algorithms, padding schemes etc.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 286
On 27/01/2017 10:06, Gervase Markham wrote:
On 26/01/17 14:12, Jakob Bohm wrote:
Given that Mozilla has been reducing the scope and generality of their
root store over the past few years, I would suggest reaching out to
those organizations that base their public root stores on the Mozilla
store
ificates
which were still valid that had not previously been revoked within the 24
hour CA/B Forum guideline - these certificates each had "O=test". Our
investigation is continuing.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Sø
ideline - these certificates each had "O=test". Our
investigation is continuing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Enjoy
Jakob
--
Jakob Bohm,
https://packages.debian.org/sid/ca-certificates
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Mana
On 25/01/2017 09:40, okaphone.elektron...@gmail.com wrote:
On Wednesday, 25 January 2017 08:25:41 UTC+1, Jakob Bohm wrote:
Tiny nit: What if the original language of the CP/CPS is English. Then
there can't be a "translation" etc.
Mmmm... indeed.
It actually says "The En
ds for URLs for both the
original language version and the English language version of each document.
This is: https://github.com/mozilla/pkipolicy/issues/6
Tiny nit: What if the original language of the CP/CPS is English. Then
there can't be a "translation" etc.
Enjoy
Jak
certificates expire.
Those obvious examples make it important to explicitly consider and
decide which of the EE requirements happen to be the same for CA
certs, and not just blindly copy rules.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29,
e victim
domain admin, so there is a lot less to make the victim organization
aware what is going on. Not sending e-mails to legitimate users is
necessary because of the need to facilitate automation with the short
certificate lifespans and other limitations of the Let's encrypt system.
E
On 20/01/2017 00:35, Nick Lamb wrote:
On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm wrote:
Google's CT initiative in its current form has serious privacy problems
for genuine certificate holders. I applaud any well-run CA that stands
up to this attack on the Internet at large
encyreport/https/ct/
Not at all relevant to this newsgroup.
...somebody has to lead by example and soon!
Hopefully not you.
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-bindin
On 18/01/2017 16:20, Gervase Markham wrote:
On 17/01/17 23:27, Jakob Bohm wrote:
Notes on the text in that branched section (other than the actual
change discussed here):
This paranthesis indicates none of these are in scope for this
particular issue, just something that might be their own
On 18/01/2017 01:12, Nick Lamb wrote:
On Tuesday, 17 January 2017 23:34:20 UTC, Jakob Bohm wrote:
How about "_and versions and strong (>= 256 bits) hashes_",
Frankly any _cryptographic_ hash should be adequate for this purpose. Even for
the most creaky crypto hashes I can think
d have no problem
generating such hashes for the documents audited, and a future update
of the Mozilla "CA community portal" might include a script that checks
these hashes while archiving the CP/CPS documents.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
T
s no set of non-ETSI audit criteria for e-mail certificates as
trusted by Mozilla Thunderbird.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may co
their
issuance infrastructure, both testing that certificates are issued for domains
they should be, and that they are not issued for domains that they should
not be, under an adversarial threat model.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29,
domain (hostmas...@example.com).
Google (for non-certificate purposes) used to verify a url that just
had to return a string that said "google-site-verification: URL" where
URL was the file name part of the Url, this may or may not have been
foolable. This was done per exact domain.
c EC functions,
it doesn't list curves that won't work in that particular context.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may con
ces exist.
But it seems most objections have been ignored and the draconian rule
instated.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-bindi
401 - 500 of 644 matches
Mail list logo
