Hi all,
There are still some problems in IP address in certificate.
Yes, we tested it that have the conclusion that all browser support IP address,
see below email.
But the test is not full covered all situation, if the certificate common name
is a domain and the SAN have IP address like this w
First case is worrying, in that it means the root private key isn't offline or
air-gaped.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On Thu, 10 Mar 2016 00:58:07 +
Peter Gutmann wrote:
> Andrew Ayer [a...@andrewayer.name] writes:
>
> >Are there clients that will choke if they receive a response without
> >the expected nonce?
>
> See my previous message, since no public CAs honour nonces [0] I
> don't think there'd be any
Andrew Ayer [a...@andrewayer.name] writes:
>Are there clients that will choke if they receive a response without the
>expected nonce?
See my previous message, since no public CAs honour nonces [0] I don't think
there'd be any problem.
Peter.
[0] At least as of the last check a few years ago.
__
On Wed, 9 Mar 2016 21:40:32 +0100
Jakob Bohm wrote:
> 1. Use a non-CA OCSP certificate if the relevant clients are known to
>support this aspect of the OCSP protocol (I don't know if any OCSP
>clients, historic or otherwise, lack this ability).
Using a dedicated OCSP responder certificat
On Tue, 8 Mar 2016 13:58:21 -0800
Andrew Ayer wrote:
> 2. Forbid OCSP nonces. OCSP nonces are optional in practice and it's
> always risky to sign arbitrary attacker-controlled data. Or, limit
> nonces to 32 bytes, which is long enough for an anti-replay nonce
> but probably too short to exploi
On 10/03/2016 00:22, Peter Gutmann wrote:
Jakob Bohm writes:
2. Find a way to add OCSP responder chosen random data in each OCSP
response.
Responder or requester? You've got the OCSP nonce, although since every
(public) CA has disabled it that probably won't help much. OTOH since client
On Wed, Mar 9, 2016 at 12:40 PM, Jakob Bohm wrote:
> 1. Use a non-CA OCSP certificate if the relevant clients are known to
> support this aspect of the OCSP protocol (I don't know if any OCSP
> clients, historic or otherwise, lack this ability). Such an OCSP
> certificate needs to be issued
Jakob Bohm writes:
>2. Find a way to add OCSP responder chosen random data in each OCSP
> response.
Responder or requester? You've got the OCSP nonce, although since every
(public) CA has disabled it that probably won't help much. OTOH since clients
won't be checking the nonce because of thi
On Wednesday, October 21, 2015 at 12:18:26 PM UTC-7, Kathleen Wilson wrote:
> FNMT has applied to include the "AC RAIZ FNMT-RCM" root certificate and
> enable the Websites trust bit.
>
> Fábrica Nacional de Moneda y Timbre (FNMT) is a government agency that
> provides services to Spain as a nati
On 09/03/16 21:04, Richard Barnes wrote:
On Wed, Mar 9, 2016 at 4:01 PM, Jeremy Rowley
wrote:
Restricting by root isn't feasible. The browsers limit the number of root
CAs each CA can have.
[citation-needed] (?)
Here's one example:
https://www.apple.com/certificateauthority/ca_program.htm
There isn’t that policy. It used to be a limit of three in the old MS policy,
which is why all roots came in threes until things started getting sold off and
passed around. As for source, it was always a CAB Forum discussion back under
Tom Albertson. I can probably find the notes in the old CAB
On Wed, Mar 9, 2016 at 4:01 PM, Jeremy Rowley
wrote:
> Restricting by root isn't feasible. The browsers limit the number of root
> CAs each CA can have.
[citation-needed] (?)
I'm not aware of any such restriction in the Mozilla policy. And in fact,
this discussion seems like a good reason for
Restricting by root isn't feasible. The browsers limit the number of root
CAs each CA can have., meaning most CAs chain Code Signing and Client chain
to the same root as server certs.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.co
On 09/03/2016 20:03, Yuhong Bao wrote:
I know of one blocker: Microsoft. Their TechNet article at aka.ms/sha1 says
that CAs are allowed to use SHA-1 and SHA-2 for OCSP signing certs and OCSP
responses, to allow continued support for XP SP1 and 2, and Server 2003. Using
SHA-2 only for OCSP sign
On 09/03/16 19:03, Yuhong Bao wrote:
I know of one blocker: Microsoft. Their TechNet article at aka.ms/sha1 says
that CAs are allowed to use SHA-1 and SHA-2 for OCSP signing certs and OCSP
responses, to allow continued support for XP SP1 and 2, and Server 2003. Using
SHA-2 only for OCSP signin
> I know of one blocker: Microsoft. Their TechNet article at aka.ms/sha1 says
> that CAs are allowed to use SHA-1 and SHA-2 for OCSP signing certs and OCSP
> responses, to allow continued support for XP SP1 and 2, and Server 2003.
> Using SHA-2 only for OCSP signing certs and OCSP responses will
> I would note that we could also combine these responses. For example, we
> might require that CAs retire SHA-1 for OCSP with a long-ish horizon, but
> require them to use constrained OCSP certs basically ASAP.
>
> Of course, if we could just turn off SHA-1 for OCSP, that would be
> fantastic.
Hi Andrew
Thank you for making us aware of this issue with our OCSP responder.
We did make a major change in our CAs some years ago where we among other
things established a new OCSP responder for all Buypass CAs used for
SSL/TLS-certificates (including Buypass Class 2 CA 1). However, the origi
19 matches
Mail list logo
