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 Sc
On Mon, May 23, 2016 at 5:28 PM, Rob Stradling
wrote:
> On 23/05/16 21:59, Richard Barnes wrote:
>
>
>> They're starting from the viewpoint that using the EKU extension as
>> a constraint mechanism is not compatible with RFC5280, but that
>> clearly there's a need for an EKU constrai
On 23/05/16 21:59, Richard Barnes wrote:
They're starting from the viewpoint that using the EKU extension as
a constraint mechanism is not compatible with RFC5280, but that
clearly there's a need for an EKU constraint mechanism.
I don't how on earth they expect to persuade Mozil
On Mon, May 23, 2016 at 4:41 PM, Rob Stradling
wrote:
> On 23/05/16 18:59, Kathleen Wilson wrote:
>
>
>> It has been pointed out to me, that I should not have added the "or"
>> without updating the next bullet point.
>>
>> So, here's what I changed it to:
>>
>>
>> https://wiki.mozilla.org/CA:Sal
On 23/05/16 18:59, Kathleen Wilson wrote:
It has been pointed out to me, that I should not have added the "or" without
updating the next bullet point.
So, here's what I changed it to:
https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesfo
On Wednesday, May 18, 2016 at 2:10:15 PM UTC-7, Kathleen Wilson wrote:
> 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
> > "
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 an
On 5/19/16 9:02 AM, Ben Wilson wrote:
What about when Microsoft starts to rely on the SalesForce
> database? Won't they want more information, including code
> signing and other information they might consider relevant?
Possibly. That will be for Jody to decide.
My approach to Salesforce so f
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:
~~
https://www.mozilla.
icert@lists.mozilla.org] On
Behalf Of Rob Stradling
Sent: Thursday, May 19, 2016 9:54 AM
To: Dimitris Zacharopoulos
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: When does Technically Constrained != Technically Constrained?
On 19/05/16 15:23, Dimitris Zacharopoulos wrote:
> On 19/5/2
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.
Dimi
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.
Dimitris, are we looking at the same version of the M
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 interm
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:
htt
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
> permittedSub
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, at
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), stateOrPr
17 matches
Mail list logo
