, which had serious problem some time ago?
- Who else (besides KIR) is still using this software to run a public
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
this example) Mozilla. In particular Mozilla could issue (2nd
intermediate) which is neither audited not disclosed.
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
iously vulnerable to future attacks on the CA key, at least
this provides a safety margin where the mitigations mentioned above
are likely to be available.
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
akes those distinctions in their
SubCA contract terms, or if you made those distinctions when CertCenter
signed up.
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
. (Not that this
is a requirement, see other replies).
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
> https://crt.sh/?id=146656935, 2017-05-31, 2019-06-05, DigiCert ECC Secure
> Server CA
> https://crt.sh/?id=307593001, 2017-06-01, 2019-01-15, DigiCert SHA2 Secure
> Server CA
> https://crt.sh/?id=308273560, 2017-06-27, 2020-07-01, DigiCert SHA2 Secure
> Server CA
>
> Assec
On 03/01/2019 16:46, Kurt Roeckx wrote:
On 2019-01-03 16:25, Jakob Bohm wrote:
There is the date fields in the SubCA certificate itself, as well as any
embedded CT data (assuming the parent CA is correctly CT-logged).
Do you expect precertificates for CA certificates?
I currently don't know
On 02/01/2019 23:40, Wayne Thayer wrote:
> On Wed, Jan 2, 2019 at 11:32 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 02/01/2019 17:17, Wayne Thayer wrote:
>>> The options to consider are:
>>> 1. Conti
On 30/12/2018 14:18, Nick Lamb wrote:
On Thu, 27 Dec 2018 22:43:19 +0100
Jakob Bohm via dev-security-policy
wrote:
You must be traveling in a rather limited bubble of PKIX experts, all
of whom live and breathe the reading of RFC5280. Technical people
outside that bubble may have easily
Happy new year,
On 30/12/2018 01:32, Peter Bowen wrote:
>
>
> On Thu, Dec 27, 2018 at 8:43 PM Jakob Bohm via dev-security-policy
> <mailto:dev-security-policy@lists.mozilla.org>> wrote:
>
> So absent a bad CA, I wonder where there is a rule that subscr
On 29/12/2018 15:32, Ryan Sleevi wrote:
> On Fri, Dec 28, 2018 at 11:21 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>> My guess is all CAs have something like
>>> https://www.digicert.com/certificate-term
On 28/12/2018 19:44, Lee wrote:
> On 12/27/18, Jakob Bohm via dev-security-policy
> wrote:
>> Looking at the BRs, specifically BR 4.9.1, the reasons that can lead
>> to fast revocation fall into a few categories / groups:
> <.. snip ..>
>> So absent a bad C
in the first place.
So absent a bad CA, I wonder where there is a rule that subscribers
should be ready to quickly replace certificates due to actions far
outside their own control.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg
On 27/12/2018 18:03, Nick Lamb wrote:
> On Thu, 27 Dec 2018 15:30:01 +0100
> Jakob Bohm via dev-security-policy
> wrote:
>
>> The problem here is that the prohibition lies in a complex legal
>> reading of multiple documents, similar to a situation where a court
>>
On 27/12/2018 17:28, Ryan Sleevi wrote:
On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Yes, you are consistently mischaracterizing everything I post.
My question was a refinement of the original question to the on
On 27/12/2018 17:13, Jakob Bohm wrote:
On 27/12/2018 17:02, Rob Stradling wrote:
On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
browserWwwServerAuth" . WWW is mentioned only in a c
On 27/12/2018 17:02, Rob Stradling wrote:
On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
browserWwwServerAuth" . WWW is mentioned only in a comment under the
OID definition.
Hi Jakob.
On 27/12/2018 16:55, Ryan Sleevi wrote:
On Thu, Dec 27, 2018 at 10:41 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
He described three combined conditions to be met. You've described a
situation "What if you meet two, but not three&
On 27/12/2018 16:24, Ryan Sleevi wrote:
> On Thu, Dec 27, 2018 at 9:34 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 26/12/2018 22:42, Peter Bowen wrote:
>>> In the discussion of how to handle certain certificates
On 27/12/2018 16:16, Ryan Sleevi wrote:
On Thu, Dec 27, 2018 at 9:30 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not
confined to Web Browsers surfing online
d by the
general public using a Mozilla web browser unless they are
> - committed to complying with a 24-hour (wall time) response time
> certificate replacement upon demand by Mozilla?
Which I have repeatedly argued is extremely onerous on a huge subset of
all server operators.
Enjoy
quot;Public TLS PKI", which is not
confined to Web Browsers surfing online shops and social networks, and hasn't
been since at least the day TLS was made an IETF standard.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmar
the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification. Applications with specific
requirements MAY use such names, but they must define the semantics.
A different RFC defines the mod
On 18/12/2018 18:15, Ryan Sleevi wrote:
> On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 10/12/2018 18:09, Ryan Sleevi wrote:
>>> On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via
w the rules for ARPANET host names. They must
>> start with a letter, end with a letter or digit, and have as interior
>> characters only letters, digits, and hyphen. There are also some
>> restrictions on the length. Labels must be 63 characters or less.
>
And this parag
evoked
> immediately and not published.
> Microsec supports the Certificate Transparency and all the TLS
> precertificates are sent to 3 CT log servers bedfore the issuance, but it did
> not happen with the CISCO VPN server certificates
>
>>
>> Our questions are:
>>>
e VPN clients) work with certificates that omit all the TLS-
related EKUs, thus allowing future VPN certificates to fall outside the
BRs ?
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 mes
On 05/12/2018 01:05, Nick Lamb wrote:
> On Tue, 4 Dec 2018 14:55:47 +0100
> Jakob Bohm via dev-security-policy
> wrote:
>
>> Oh, so you meant "CA issuance systems and protocols with explicit
>> automation features" (as opposed to e.g. web server systems or
>
ly what I’m saying - that the industry has not actually matured
>>> as you suggest. What has changed has largely been driven by those outside
>>> CAs - whether those who were wanting to become CAs (Amazon with certlint)
>>> or those analyzing CA’s failures (ZLint).
>>&
On 04/12/2018 13:36, Nick Lamb wrote:
On Tue, 4 Dec 2018 07:56:12 +0100
Jakob Bohm via dev-security-policy
wrote:
Which systems?
As far as I'm aware, any of the automated certificate issuance
technologies can be used here, ACME is the one I'm most familiar with
because it is going through
On 04/12/2018 05:38, Nick Lamb wrote:
> On Tue, 4 Dec 2018 01:39:05 +0100
> Jakob Bohm via dev-security-policy
> wrote:
>
>> A few clarifications below
>> Interesting. What is that hole?
>
> I had assumed that you weren't aware that you could just use these
>
A few clarifications below
On 30/11/2018 10:48, Nick Lamb wrote:
> On Wed, 28 Nov 2018 22:41:37 +0100
> Jakob Bohm via dev-security-policy
> wrote:
>
>> I blame those standards for forcing every site to choose between two
>> unfortunate risks, in this case either the
t the worst case scenario is not the performance
optimization point, it is OK if running in this mode will entail horribly
slow performance, as long as it stays within the absolute maximums set by
standards, BRs, CPS etc. For example, OCSP responders might start taking
seconds to return each r
On 27/11/2018 00:54, Ryan Sleevi wrote:
> On Mon, Nov 26, 2018 at 12:12 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> 1. Having a spare certificate ready (if done with proper security, e.g.
>> a separate key) from a dif
, it is unclear why a Bundesamt belongs to an identification
jurisdiction lower than the entire BDR.
For comparison, Danish Company entities are fully identified by the
numeric part of their VAT number (or a number from the same national
database if it has no VAT registration), and this is
a
validation method had a vulnerability, but not knowing which if any of
the validated identities were actually fake). For example to recheck a
typical domain-control method, a CA would have to ask each certificate
holder to respond to a fresh challenge (lots of manual work by end
sites), then do the actual che
Once again, you snipped most of what I wrote.
Also not sure why your post has double reply marking.
On 13/11/2018 18:20, Ryan Sleevi wrote:
>>
>>
>>
>> On Tue, Nov 13, 2018 at 11:26 AM Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozil
the issuing process. Many
in the area of technically (not semantically) validating the data
inserted into templates. For example, allowing absolute form DNS names
when the RFCs require root-relative DNS names with the root period
omitted. No amount of checking and reviewing the templates cou
f issue U1 was in a template, it would likely not have been caught
by measures based on the identified root causes of the issues in
bug#1391074.
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 pub
ansit, making it difficult to tell what sentences are replies to what
prior messages. If you are using a Microsoft client, there may be an
advanced configuration option to do so.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +4
On 09/11/2018 15:52, Hanno Böck wrote:
On Fri, 9 Nov 2018 14:56:41 +0100
Jakob Bohm via dev-security-policy
wrote:
However there are also some very harsh punishments handed out, such as
distrusting some CAs (most notably happened to Symantec and WoSign,
but others are also teetering
ruly misissued to the wrong person.
Each of these arguments for maximum punishment and/or maximum
inconvenience for innocent bystanders is backed by a formal/legal
interpretation of existing rules as making this the only possible
outcome.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. h
On 09/11/2018 07:21, Ryan Sleevi wrote:
On Thu, Nov 8, 2018 at 5:51 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
This thread is for the general principles, it takes no stance on any
particular cases, as that would quickly derail the discussion.
fair for everybody
directly or indirectly affected.
Furthermore, people with some clout tend to shut down all
counterarguments when taking either extreme position, creating situation
there only their own position is heard, making the entire "community"
aspect an illusion.
Enjoy
Jakob
--
J
roots
1.1.2.10 Experimental roots
1.6.5 Non-Normative references
3.1.7 Territorial name restrictions
4.9.17 Availability of historic revocation information
4.9.17.3 Historic revocation information for e-mail certificates. etc.
4.13 Intermediary CA certificate rotation procedures.
Enjoy
Jakob
--
Jako
ean
is sufficient.
- Added bullet points
- Added "Sections MUST not be left blank. ..."
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS
_Structured_According_to_RFC_3647
I continue to appreciate your feedback on this new section.
Enjoy
Jakob
--
Jakob Bo
ertificate
with the same serial number. If there are OCSP privacy features etc.
4.11 (Mostly relevant to customer relationship)
4.12 Key escrow and recovery policy and practices
This is the subject of a Mozilla requirement (not to provide such).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A
requests an Identrust certificate).
..int contains almost exclusively high value domains such as un.int,
nato.int etc.
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
.2FCPS_Structured_According_to_RFC_3647
links directly to the edited section.
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
CRLs covering the same date
range would already be significant evidence against any such rogue 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
Good to know!
CT logs are not CRLs or OCSP responders, nor do they track revocation.
- Matt
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
old Section 4.2 of RFC5280, it explicitly violates
5.2 of the Mozilla policy. That is, it was so important a policy requirement
that it exists twice - in the BRs and in Mozilla Policy - and is alternatively
worded so as to explicitly prohibit any confusion by CAs about the expectations.
Enjoy
ld expect one of the 2
documents to clearly state the operational practices of the CA rather than
just stating "No Stipulation" in both CP & CPS, unless the Policy Qualifier
in issued certificates points to some other document that contains that
information.
Again - just my persona
] https://crt.sh/mozilla-disclosures#undisclosed
[5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed
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
ResponsesOnlyReport?CommunicationId=a051J3rMGLL=Q00078,Q00079
[4] https://crt.sh/mozilla-disclosures#undisclosed
[5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Sø
On 04/10/2018 19:40, Wayne Thayer wrote:
On Thu, Oct 4, 2018 at 9:48 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
(In reply to Matt Palmer in message-id
mailman.78.1538620059.2924.dev-security-pol...@lists.mozilla.org)
I seem to recall that t
long discussion and some posts
have been expired by the mozilla NNTP server.
...
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.
signed and our DNS query times out.
If any of these cases are encountered, the certificate request is automatically
blocked and the
applicant is notified by email of the need to update the associated DNS records.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Trans
ted in your CP / CPS are not fully
enforced by automated systems? (Your answers suggest at least one,
so make sure your answer is complete).
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 publi
the CA) containing only the minimum
number of attributes (serial number only for now) for each issued
certificate?
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
8 10:45 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Telia CA - problem in E validation
I believe it has been useful to our users even though it was only
partially
verified like OU. Now when it no more exists it certainly won't provide
any help
to anybody.
browser will be
configured to trust that CA for any end-user not manually overriding
that decision.
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 contai
and is the subject of some serious public
prosecution. Cow-towing to that mastodont is not buy-in or agreement,
merely fear.
The rest of your proposal follows from your bad premises and must be
rejected.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej
try not feed
that troll as it would only end in tears.
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
former domain owner time to get a new (DV) certificate
without the bygone domain, while waiting for the full validation of an
OV or EV cert if wanted (Consider the case of the bygone domain being
lost due to a an unfair domain dispute ruling or other adverse event).
Enjoy
Jakob
--
Jakob Bohm,
ssued to natural persons, this should be their legal name, again
subject to some notational variations enumerated in the 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 i
On 27/07/2018 08:46, Jakob Bohm wrote:
On 26/07/2018 23:04, Matthew Hardeman wrote:
On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The party actually running the authoritative DNS servers is in control
of the domain
tion unchanged, but subject requests revocation. Also common.
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 Man
probably weren't intending to do that". It's cert*lint*, not
certstrictcompliancecheckertoarbitraryunworkablerules.
Peter.
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.
Wis
On 01/06/2018 21:01, Wayne Thayer wrote:
On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Please contact the CA again, and inform them that BR 4.9.1.1 #6 requires
the CA (not some reseller) to revoke the certificate wit
situations such as BGP attacks, DNS
attacks, rogue hosting providers, all of which are common problems.
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
terminated, or the Domain Name Registrant has
failed to renew the Domain Name);
While CAs are not required to discover such situations themselves, they
must revoke once made aware of the situation (in this case by you
telling them).
At least, this is how I read the rules.
Enjoy
Jakob
--
Jakob
on the nature of the e-mail system involved.
A company postmaster has obvious supremacy over company e-mail accounts.
But a common carrier ISP postmaster should not have supremacy over their
users.
On Mon, May 14, 2018 at 12:10 PM, Jakob Bohm via dev-security-policy <
dev-security-pol
blance to the
3rd party CA scenario.
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 fo
to in order
to be
trusted.
Right now, CAs are only required to check CAA for server-type
certificates
(by virtue of the Baseline Requirements Section 3.2.2.8).
CAs are not presently being required to check CAA for e-mail. They
can, but
they are required to do it, so they are unlikely to do it.
he openssl-blacklist-extra package which contains the lists
of RSA-4096 and RSA-512 keys.
Their included checking program (in the .diff file) is in Python.
URL: http://ftp.de.debian.org/debian/pool/main/o/openssl-blacklist/
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.
a different mechanism than PKCS#12 encryption for turning an
insecure channel into a secure private key delivery mechanism.
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
e holder (for
example C=US, O=Google Inc would be a permitted dirname subtree
constraint for a subCA issued to the US headquarters of Google Inc.
The validation must be done to standards above and beyond the
standards required for end entity certificates of the types that the
SubCA can issue.
Enjo
records of whois servers, DNS records for downloading any 3rd party
blocklists).
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
better.
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, Pho
unencrypted). The list of insecure electronic channels is
infinite.
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 - Remot
/rootcert
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-TQ8/hgVsCofcAgAJ
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 17/04/2018 00:13, Ryan Sleevi wrote:
On Mon, Apr 16, 2018 at 3:22 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
If that CA has a practice that they actually do something about high
risk names, it would still be expected (in the normal, not
GoDaddy has made such a claim, and we
ought not put words in their mouths.
Alex
On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 13/04/2018 18:07, Ryan Sleevi wrote:
Indeed, it was a public demonstration that they'll h
On 13/04/2018 19:18, Ryan Sleevi wrote:
On Fri, Apr 13, 2018 at 1:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Possible outcomes of such an investigation:
1. That CA does not consider paypal to be a high risk name. This is
within their
On 13/04/2018 18:05, Ryan Sleevi wrote:
On Fri, Apr 13, 2018 at 11:53 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 13/04/2018 05:56, Ryan Sleevi wrote:
On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via
dev-security-policy <
dev
e it in enough water to put out a real fire.
Everybody knows it's just a make-believe drill, but they proceed to
demonstrate their abilities to handle the make-believe situation,
because doing so is kind of the point of having a drill in the first
place.
On Fri, Apr 13, 2018 at 12:00 PM, Jakob B
rate test of the law. Of cause, such an actor might
deserve some leniency in the punishment, such as a $1 fine, but he
should not be surprised the law is formally upheld.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Di
On 06/04/2018 03:04, Matt Palmer wrote:
On Thu, Apr 05, 2018 at 09:05:07PM +0200, Jakob Bohm via dev-security-policy
wrote:
On 04/04/2018 04:27, Matt Palmer wrote:
On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via dev-security-policy
wrote:
On 02/04/2018 18:26, Tom Delmas wrote
On 04/04/2018 04:16, Matt Palmer wrote:
On Tue, Apr 03, 2018 at 03:16:53AM +0200, Jakob Bohm via dev-security-policy
wrote:
On 03/04/2018 02:35, Kurt Roeckx wrote:
On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy
wrote:
seems
to be mostly justified as a poor
On 04/04/2018 16:01, Ryan Sleevi wrote:
On Tue, Apr 3, 2018 at 11:42 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 03/04/2018 14:57, Ryan Sleevi wrote:
On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy <
dev-securi
he
certificate is preemptively revoked due to private key compromise and
issuance is retried with a new key.
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
On 03/04/2018 14:57, Ryan Sleevi wrote:
On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 03/04/2018 02:15, Wayne Thayer wrote:
On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
dev-securi
On 03/04/2018 02:35, Kurt Roeckx wrote:
On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy
wrote:
seems
to be mostly justified as a poor workaround for the browsers and
certificate libraries not properly implementing reliable revocation
checks.
The problem
On 03/04/2018 02:15, Wayne Thayer wrote:
On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
While Entrust happens to do this, as a relying party, I dislike frequent
updates to CP/CPS documents just for such formal c
ates has been discussed many
times,
but
to
rehash: They afford the ecosystem significantly more agility, by
allowing
us to
remove mistakes in shorter periods of time without breaking valid
certificates.
It also encourages subscribers to adopt more automation, which
further
helps
w
in both a
published CRL and in OCSP. It would be counter to security to require
issuance in the few cases where misissuance is detected between CT
Pre-cert logging and actual issuance.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg
or no reason at all).
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
ss
soon before/after the cross signing, but benefiting from the cross-
signature until relying parties receive the updated root store that
trusts that other CA.
So in neither case do I see a need to re-audit the parent CA.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https:
/pkipolicy/blob/2.5/rootstore/policy.md
Will that make such audits (prior to the deadline) unacceptable as part
of the unbroken audit chain back to first issuance for new roots?
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark
101 - 200 of 570 matches
Mail list logo
