rolled out.
If you take over the roots, why continue to keep separate roots for the
former Symantec brands (except as an "old hierarchy used mostly for
their own CRLs and historic relying parties such as certain Microsoft
products")?
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner
generally (for all visitors), or behind some special logic to
only use it for some known-broken client types.
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
On 31/07/2017 16:06, Gervase Markham wrote:
On 31/07/17 15:00, Jakob Bohm wrote:
It was previously stated in this newsgroup that non-SSLServer trust
would not be terminated, at least for now.
It was? Reference, please?
That was my general impression, I don't have a good way to search
milar to the old "GeoRoot" program),
it would be best to put that under separate roots.
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
lapses in its operations. The world did not end.
Note that DigiNotar was a country-local CA, not a global CA. The risk
profile (for distrust, not for mis-issuance) was much lower.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark
we recognize there are further
opportunities to improve this for Certificate Authority decisions. As
those improvements are not yet in place, we will be forgoing the Blink
API owner LGTM process for approval, and treating this more as a
product-level decision instead.
Thanks to everyone who put
ued before
Jun 1, 2016 on December 1, 2017?
So far most of the discussion seems to have been about distrusting
Symantec certs issued after December 1, 2017, at least as I read it.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmar
s.
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
ore detail
and look for ways that we can integrate these ideas into the research we are
doing.
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
(who might otherwise
just log the accesses to one of their own servers during a legitimate
request).
A public many-locations VPN service such as TOR could be used as a
supplemental check, but cannot be audited to CA network security
standards and thus would be an additional check.
Enjoy
Jak
for EV code signing certificates
(which may include e-mail addresses) for inspiration.
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
On 19/07/2017 17:31, Steve Medin wrote:
-Original Message-
From: dev-security-policy [mailto:dev-security-policy-
bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
Jakob Bohm via dev-security-policy
Sent: Tuesday, July 18, 2017 4:39 PM
To: mozilla-dev-security-pol
of this Managed CA plan.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej
On 18/07/2017 16:44, Rob Stradling wrote:
On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote:
On 18/07/2017 16:19, Rob Stradling wrote:
On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni
Enhanced” which
rtificates that exhibit this
"double dot" problem. I've submitted both of them to some CT logs:
https://crt.sh/?id=174668364
https://crt.sh/?id=174668366
We will revoke all 3 of these leaf certificates ASAP.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Tra
se, what is the proper
place to lobby for adoption of standards?
Thanks,
Matt Hardeman
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 14/07/2017 21:04, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
That's my point. The current situation is distinct from weak keys, and
we shouldn't sacrifice the weak keys BR to mak
On 14/07/2017 18:19, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 14/07/2017 15:53, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-securi
ficate is probably the safest choice, as it ensures that
"key compromise" is no different from any other rotation, and keeps that
hinge well oiled.
His scenario did include "Key X compromised" .
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
T
On 14/07/2017 15:53, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an e
elves,
except when the revocation was mistaken (this happens, and in that case,
reusing the key is not a big problem).
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
alternative identifiers for some some EU
member states.
That said, it could provide some inspiration.
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
e one loosely described at http://unmitigatedrisk.com/?p=259
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 Servi
an auditor.
This could become the canonical place for Mozilla and other CCADB-based
root programs to indicate when they override the trust programs
(WebTrust, ETSI, ...) decision on this.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg
than the normal Microsoft root program. Chain
validation is often done during boot before TCP/IP is up and running
(even the network drivers are signed with this), so there is no AIA or
OCSP available. Pre-download CRLs could be checked, but I don't know if
they do that.
Enjoy
Jakob
--
Jakob Bohm
On 22/06/2017 15:02, Ryan Sleevi wrote:
On Thu, Jun 22, 2017 at 1:59 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> (Snip long repeat of the same opinion)
You seem to argue:
- Because the recent research on efficient central CRL dis
by default.
Note that the real world time to achieve #2..#4 is unfortunately
significant, hence my suggesting to use #1 as a faster solution.
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
truly complex scenarios, more complex techniques are needed to
avoid distributing private keys, but that's not needed for the cases
discussed here.
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 20/06/2017 08:08, Gervase Markham wrote:
On 20/06/17 01:21, Jakob Bohm wrote:
2. For any certificate bundle that needs to be incorporated into the
Mozilla root stores, a significant period (3 to 6 months at least)
will be needed between acceptance by Mozilla and actual trust
On 20/06/2017 09:05, Ryan Sleevi wrote:
On Mon, Jun 19, 2017 at 7:01 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
NSS until fairly recently was in fact used for code signing of Firefox
extensions using the public PKI (this is why there is a d
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct
take on their part, but a very likely mistake.
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 Managemen
On 09/06/2017 12:29, Rob Stradling wrote:
On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote:
What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?
And would someone please post those alleged certific
r them to be in scope. However,
the policy trumps my opinion).
What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?
And would someone please post those alleged certificate chains
*explicitly* here, not just say they sa
econfigured to trust that local root CA.
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
SSL certificates
in the scope of this policy to conform to the Baseline Requirements.
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.
Wise
On 08/06/2017 18:52, Peter Bowen wrote:
On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
As the linked proposal was worded (I am not on Blink mailing lists), it
seemed obvious that the original timeline was:
Later
On 08/06/2017 11:09, Gervase Markham wrote:
On 07/06/17 22:30, Jakob Bohm wrote:
Potential clarification: By "New PKI", Mozilla apparently refers to the
"Managed CAs", "Transition to a New Symantec PKI" and related parts of
the plan, not to the "new roots&qu
ozilla is allowed to give access to any member of our community that we
wish.
Potential clarification: Mozilla's #3 requirement applies to both the
"new PKI" and the "new roots" for the "new infrastructure".
We look forward to hearing Symantec's response to these
On 07/06/2017 17:41, Ryan Sleevi wrote:
On Wed, Jun 7, 2017 at 11:25 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Note that I also had a second, related, point: The possibility that such
a new piece of infrastructure was, for other r
rule would then imply that Mozilla should not reserve to
itself a power it would not want other root programs to have.
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
On 07/06/2017 12:55, Rob Stradling wrote:
On 06/06/17 22:26, Jakob Bohm wrote:
On 06/06/2017 22:08, Ryan Sleevi wrote:
Signing data is heavily reliant on CA competency, and that's in
unfortunately short supply, as the economics of the CA market make it
easy to fire all the engineers, while
On 06/06/2017 22:08, Ryan Sleevi wrote:
On Tue, Jun 6, 2017 at 2:28 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I am saying that setting an administrative policy for inclusion in a
root program is not the place to do technical reviews of se
em in access to this being subject to a reasonable
NDA that allows Mozilla to show it to their choice of up to 50 external
experts (I don't expect to be one of those 50).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Dir
On 06/06/2017 07:45, Ryan Sleevi wrote:
On Mon, Jun 5, 2017 at 6:21 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
If you read the paper, it contains a proposal for the CAs to countersign
the computed super-crl to confirm that all entries for t
On 02/06/2017 17:12, Ryan Sleevi wrote:
On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 02/06/2017 15:54, Ryan Sleevi wrote:
On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen <pzbo...@gmail.com> wrote:
On Fri, Jun
use it was not yet on the old list {Certificate, CRL}.
Hence my suggested phrasing of "Anything that resembles a certificate"
(my actual wording a few posts up was more precise of cause).
Note that signing a wrong CRL or OCSP response is still bad, but not
mis-issuance.
Enjoy
Jakob
--
s and OCSP
responses).
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,
On 23/05/2017 18:18, Ryan Sleevi wrote:
On Tue, May 23, 2017 at 11:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Note as this is about a proposed future policy, this is about validation
code updated if and when such a policy is enacted. C
On 23/05/2017 16:22, Ryan Sleevi wrote:
On Tue, May 23, 2017 at 9:45 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
* TCSCs can, by their existing definition, be programmatically
recognized by certificate validation code e.g. in browsers and
ogging, properly written
certificate validation code should simply not impose this below TCSCs.
With the above and similar measures (mostly) already in place, I see no
good reason to subject TCSCs to any of the administrative burdens
imposed on public SubCAs.
Enjoy
Jakob
--
Jakob Bohm, CIO, Par
will need to do it anyway. But I will investigate in
discussions whether some scheme like this might be acceptable to both
the other two sides and might lead to a quicker migration timetable to
the new PKI.
Gerv
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformer
Comments inline
On 20/05/2017 16:49, Michael Casadevall wrote:
Comments inline.
On 05/19/2017 05:10 PM, Jakob Bohm wrote:
Suggested trivial changes relative to the proposal for Mozilla use:
3. All non-expired Symantec issued certificates of any kind (including
SubCAs and revoked certificates
y assigns to all bug reports. The 48 hours
allowed post-incident even if someone else is quick to report the
incident is intended to just give Symantec Management time enough to
literally actually wake up, go to work, notice the misbehavior or other
incident and then quickly issue a report. The exact number
nt without success.
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
indicating unknown country
(if permitted in the X.500 standards).
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 - Remo
On 19/05/2017 16:15, Gervase Markham wrote:
On 19/05/17 14:58, Jakob Bohm wrote:
Because the O and other dirname attributes may be shown in an e-mail
client (current or future) as a stronger identity than the technical
e-mail address.
Do you know of any such clients?
No, but it would
to any range of DNs.
It would be problematic for such a SubCA to be considered a TCSC
excluded from all usual checks and balances.
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 discu
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
On 16/05/2017 18:10, Peter Bowen wrote:
On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
Your post above is the first response actually saying what is wrong
with the Microsoft format and the first post saying all the
restri
On 16/05/2017 17:10, Peter Bowen wrote:
On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
On 13/05/2017 00:48, Ryan Sleevi wrote:
And in the original message, what was requested was
"If Mozilla is interest
On 13/05/2017 00:48, Ryan Sleevi wrote:
On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about
suggesting a good format for sharing this info across lib
--
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 and Embedded
using community :)
Can you please get it into your thick skull that this thread is NOT
ABOUT NSS, IT IS ABOUT ALL THE OTHER X.509 LIBRARIES that can be
configured to use a copy of the Mozilla Root store!
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej
vendor, product and use, it
lists the incompatible products and the first fully compatible product.
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
On 15/05/2017 22:06, Michael Casadevall wrote:
On 05/15/2017 09:32 AM, Jakob Bohm wrote:
This won't work for the *millions* of legitimate, not-misissued,
end certificates that were issued before Symantec began SCT
embedding (hopefully in the past) and haven't expired before such
an early
regularly updated, at least
while relevant changes were happening in the world.
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.
WiseM
at specific historic roots that are part of our current Symantec
dilemma.
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
under the sloppy Symantec management or under
their innocent users?
And should we allow enough of Symantec to keep standing to not leave
those users who cannot switch stranded with nowhere to go but a 404
webpage?
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transf
On 12/05/2017 23:45, Ryan Sleevi wrote:
On Fri, May 12, 2017 at 2:15 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 12/05/2017 20:43, Ryan Sleevi wrote:
On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy <
dev-securi
On 12/05/2017 20:43, Ryan Sleevi wrote:
On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Could something be derived from / based on the ASN.1 format apparently
used by Microsoft in it's root store, with OpenSSL/Mozill
ather 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
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transforme
ng EKU list?
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,
On 08/05/2017 12:16, Gervase Markham wrote:
On 05/05/17 22:21, Jakob Bohm wrote:
The issue would be implementations that only check the EE cert for
their desired EKU (such as ServerAuth checking for a TLS client or
EmailProtection checking for a mail client). In other words, relying
parties
olicy or technical
requirements on certificates that Mozilla products can use for
ClientAuth (e.g. does Firefox only offer certs with the ClientAuth (or
no) EKU when prompting a user which cert to send to a webserver,
similar for Thunderbird doing ClientAuth to a TLS protected e-mail
server).
Enjoy
J
On 05/05/2017 17:37, Gervase Markham wrote:
On 04/05/17 19:30, Jakob Bohm wrote:
1. Issue D actually seems to conflate three *completely different*
issues:
Are you sure you are not referring to the Issues List document here
rather than the proposal?
I am referring to the "summary&
igned by a (new) "EV-only" root, could
Mozilla move the EV trust to that new root, thus removing the
risk of EV-trusting any other "Universal" subCAs.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.
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 mention bank robberies.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, Wis
ormal 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"
...
Enjoy
Jakob
--
Jako
licy 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.com
Transformervej 29, 2860 Søborg
ance 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, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.
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 own
s 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
Jakob
--
Jakob Bohm, CIO,
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
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
Transformervej 29,
d.
Hopefully 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.wisem
.
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
Transformervej 29, 2860 Søborg
orced 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.
WiseMo - Remote Service Management for PCs,
n, 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 +45 31
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
--
Jakob
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
--
Jakob
,
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
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.
WiseMo - Remote
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
ry 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
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors
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 - Remote Service Management
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 00:31, Peter Bowen wrote:
On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
<dev-security-policy@lists.mozilla.org> 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-securi
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
301 - 400 of 570 matches
Mail list logo
