On 23/05/16 22:41, Richard Barnes wrote:
On Mon, May 23, 2016 at 5:28 PM, Rob Stradling wrote:
Why invent a new thing?
Even if we make an old thing new, there's still the transition :)
That's true, but it would be an easier transition.
--
Rob Stradling
Senior Research & Development
On 19/05/16 17:39, Kathleen Wilson wrote:
My interpretation of the above regarding root certificates with only the Email
trust bit enabled or intermediate certificates with only id-kp-emailProtection
EKU is that in order to be technically constrained, the CA has to make sure
(via technical
On Thursday, May 19, 2016 at 6:58:36 AM UTC-7, Rob Stradling wrote:
> Specifically, what are the disclosure requirements for intermediates
> that can only issue id-kp-emailProtection and/or id-kp-codeSigning
> end-entity certs?
Quotes form policy and supporting wiki page:
~~
@lists.mozilla.org] On
Behalf Of Rob Stradling
Sent: Thursday, May 19, 2016 9:54 AM
To: Dimitris Zacharopoulos <ji...@it.auth.gr>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
<dev-security-policy@lists.mozilla.org>
Subject: Re: When does Technically Constrained != Technically Constrained?
On 19/05/16 15:23, Dimitris Zacharopoulos wrote:
On 19/5/2016 4:36 μμ, Rob Stradling wrote:
On 18/05/16 17:23, Dimitris Zacharopoulos wrote:
This intermediate seems technically constrained for SSL and S/MIME
certificates, which are the only type of certs under the current
Mozilla policy.
On 18/05/16 19:38, Kathleen Wilson wrote:
On Wednesday, May 18, 2016 at 7:17:01 AM UTC-7, Rob Stradling wrote:
However, then that page says...
"Intermediate certificates are considered to be technically constrained,
and do not need to be added to the CA Community in Salesforce if:
- The
On 18/05/16 17:23, Dimitris Zacharopoulos wrote:
This intermediate seems technically constrained for SSL and S/MIME
certificates, which are the only type of certs under the current Mozilla policy.
Dimitris, are we looking at the same version of the Mozilla policy?
I'm looking at this one:
On Wednesday, May 18, 2016 at 7:17:01 AM UTC-7, Rob Stradling wrote:
> The following intermediate certificate is not "technically constrained"
> according to the Policy. It contains id-kp-codeSigning, but does not
> "contain a directoryName permittedSubtrees constraint where each
>
This intermediate seems technically constrained for SSL and S/MIME
certificates, which are the only type of certs under the current Mozilla
policy. Having extra nameConstraints for this particular intermediate, seems to
be unnecessary, for the Mozilla root program.
DZ.
> On 18 Μαΐ 2016,
The following intermediate certificate is not "technically constrained"
according to the Policy. It contains id-kp-codeSigning, but does not
"contain a directoryName permittedSubtrees constraint where each
permittedSubtree contains the organizationName, localityName (where
relevant),
10 matches
Mail list logo
