No. The definition of Authorization Domain Name allows a CA to issue
www.example.com if the CA can prove control over example.com. However, the
reverse is not true. Proving control over www.example.com does not validate
example.com.
-Original Message-
From: dev-security-policy
On 3 October 2016 at 19:24, Jakob Bohm wrote:
> On 03/10/2016 20:41, Kyle Hamilton wrote:
>> 2. There is only One Certificate Path that can be proven in TLS, which
>> prevents risk management by end-entities.
>>
>
> Are you sure, I thought the standard TLS protocol
Hi Stefan,
On 01/10/16 00:35, Stefan Paletta wrote:
> I have one question about the proposal: what is the rationale and
> justification for the one-year minimum distrust?
The determination of the action to take in any particular case takes
account of precedent (e.g. CNNIC) and our understanding
On 30/09/16 13:40, Jakob Bohm wrote:
> Well, at least the intermediaries involved would be SHA-1 and be
> checked against the SHA-1-distrust policy?
Yes. But issuing SHA-1 from a currently-publicly-trusted root is a BR
violation, whether clients enforce distrust or not. One solution often
adopted
On 30/09/16 12:23, Gervase Markham wrote:
> We don't plan to make a video or release a transcript, but Mozilla will
> also not be finalising any plans for action at the meeting either. From
> our perspective, the aim is to discuss whatever plans
> Qihoo/StartCom/WoSign have to improve the
On 10/3/2016 11:50 AM, Peter Bowen wrote:
> 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.9, and 3.2.2.4.10 all use the newly
> defined "Authorization Domain Name", which should avoid this in the
> future.
Thank you for pointing me to those sections, but my confusion may be
starting from the definition of
On Mon, Oct 3, 2016 at 5:24 PM, Jakob Bohm wrote:
> On 03/10/2016 20:41, Kyle Hamilton wrote:
>> WoSign is known to be cross-signed by several independent CAs (as well as
>
>> 2. There is only One Certificate Path that can be proven in TLS, which
>> prevents risk management
7 matches
Mail list logo