On Thursday, 5 May 2016 13:22:34 UTC+1, Rob Stradling wrote:
> That logic would imply that all of the "Not Trusted by Mozilla"
> intermediates should be moved to "Disclosure required!", given that I
> can't prove the non-existence of cross-certificates that would cause
> these intermediates to
On Thu, May 5, 2016 at 9:56 AM, Peter Bowen wrote:
>
> > On May 5, 2016, at 6:50 AM, Richard Barnes wrote:
> >
> > On Thu, May 5, 2016 at 8:32 AM, Peter Bowen wrote:
> >>
> >> I will disagree. I think the intent is to "prune" the tree
> >
> >
> > Oh, if only it were a tree, and not a DAG. Well
> On May 5, 2016, at 6:50 AM, Richard Barnes wrote:
>
> On Thu, May 5, 2016 at 8:32 AM, Peter Bowen wrote:
>>
>> I will disagree. I think the intent is to "prune" the tree
>
>
> Oh, if only it were a tree, and not a DAG. Well, *hopefully* acyclic.
Nope, not acyclic. Already seen proof of
On Thu, May 5, 2016 at 8:32 AM, Peter Bowen wrote:
> On Thu, May 5, 2016 at 2:57 AM, Rob Stradling
> wrote:
> > RFC5280 says (emphasis mine)...
> > "4.2.1.10. Name Constraints
> >The name constraints extension, which MUST be used only in a CA
> >certificate, indicates a name space wit
On Friday, April 8, 2016 at 12:58:41 AM UTC+3, Kathleen Wilson wrote:
> The status of this discussion is that we are waiting for the CA to provide
> the following:
>
> 1) Updated/restructured CPS (both in Hebrew and translated into English).
>
> 2) Full BR Audit statement.
>
> 3) An explanation
On Thu, May 5, 2016 at 2:57 AM, Rob Stradling wrote:
> RFC5280 says (emphasis mine)...
> "4.2.1.10. Name Constraints
>The name constraints extension, which MUST be used only in a CA
>certificate, indicates a name space within which all subject names in
>*subsequent certificates in a
On 05/05/16 12:50, Kurt Roeckx wrote:
Since Intermediate 2 is effectively technically constrained, you might
imagine that it should be exempt from the disclosure requirement. However,
the "certificate MUST include...extension" language in both the Mozilla CA
Policy and the BRs seems to clearly s
On 05/05/16 10:57, Rob Stradling wrote:
Consider a certificate chain of this form:
Root
Intermediate 1 (contains Name Constraints / EKU)
Intermediate 2 (does not contain Name Constraints / EKU)
End-entity
Since Intermediate 2 is effectively technically constrained, you mig
On Thu, May 05, 2016 at 10:57:39AM +0100, Rob Stradling wrote:
> RFC5280 says (emphasis mine)...
> "4.2.1.10. Name Constraints
>The name constraints extension, which MUST be used only in a CA
>certificate, indicates a name space within which all subject names in
>*subsequent certific
On 05/05/16 11:10, Rob Stradling wrote:
On 05/05/16 10:32, Nick Lamb wrote:
On Wednesday, 4 May 2016 21:34:28 UTC+1, Rob Stradling wrote:
Thanks Nick. All suggestions welcome. :-)
Not so much a suggestion this time as a potential bug report
Potential bug reports are also very welcome. :
On 05/05/16 10:32, Nick Lamb wrote:
On Wednesday, 4 May 2016 21:34:28 UTC+1, Rob Stradling wrote:
Thanks Nick. All suggestions welcome. :-)
Not so much a suggestion this time as a potential bug report
Potential bug reports are also very welcome. :-)
"Let's Encrypt Authority X2" appears
RFC5280 says (emphasis mine)...
"4.2.1.10. Name Constraints
The name constraints extension, which MUST be used only in a CA
certificate, indicates a name space within which all subject names in
*subsequent certificates in a certification path* MUST be located."
The Mozilla CA Policy s
On Wednesday, 4 May 2016 21:34:28 UTC+1, Rob Stradling wrote:
> Thanks Nick. All suggestions welcome. :-)
Not so much a suggestion this time as a potential bug report
"Let's Encrypt Authority X2" appears twice in the table, both times it is
listed with the DST Root CA X3 issuer. However it se
On 04/05/16 23:05, Rob Stradling wrote:
On 04/05/16 22:42, Richard Barnes wrote:
On Wed, May 4, 2016 at 5:41 PM, Dimitris Zacharopoulos wrote:
https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
The above link clarifies th
14 matches
Mail list logo
