Re: [TLS] Status of X.509v3 TLS Feature Extension?

Phillip Hallam-Baker <hallam@gmail.com> Tue, 29 April 2014 20:20 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B021A0986 for <tls@ietfa.amsl.com>; Tue, 29 Apr 2014 13:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwXZwzVyBF8u for <tls@ietfa.amsl.com>; Tue, 29 Apr 2014 13:20:04 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DF2671A0958 for <tls@ietf.org>; Tue, 29 Apr 2014 13:20:03 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id hr17so558307lab.17 for <tls@ietf.org>; Tue, 29 Apr 2014 13:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d38VxHR8UpKIZGb+jQsKjmrM0XUK8qh5phJA8n2bde0=; b=u2Y38dc5eV2mCOqLew9eyjouG8VbaQKbnnd6Zj2pn6yPR9m4AkP2ZPDJtCnUCjIt0n F6LO1T/pi7lYUwf1NyquTiTUx0kHi26jlmZFPc7/OuCABVuKyhNuXjuDHaAfXIGDcXFA cM/kEwmR6FqJHQY+H/LJw610VEmfhXbtZzL14nRGSMscpXP8w/86l4C3m6i22y+owJtf KJOZspsZngE9XZ8lCSvb9mcfkCyIGuuof3Oq72lJw6lz/34ibAhgTVLyUmakGK+UcE5U 1t8/bg/B6efv/EjIDTVAFZGszsoTA1A6TmN56OvA5HLQ6MpuPoF1V5qtnXG7kmTY+2ZC 04dw==
MIME-Version: 1.0
X-Received: by 10.152.10.72 with SMTP id g8mr17358lab.50.1398802801863; Tue, 29 Apr 2014 13:20:01 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Tue, 29 Apr 2014 13:20:01 -0700 (PDT)
In-Reply-To: <CA+aixj_i8XF2buDNMOp2=_Z0XzT3R4uGfxJtjoGt-_PButSggw@mail.gmail.com>
References: <CA+aixj_i8XF2buDNMOp2=_Z0XzT3R4uGfxJtjoGt-_PButSggw@mail.gmail.com>
Date: Tue, 29 Apr 2014 16:20:01 -0400
Message-ID: <CAMm+LwhH0_gP8KL6mUBYp1sU1J7QvuM17awss2ceb4U2dovU2Q@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Klemens Baum <klemensbaum@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Sfka4eD-rEPgetCgTaFLoO9uBc
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Apr 2014 20:20:07 -0000

I just submitted an update to keep it current.

http://www.ietf.org/id/draft-hallambaker-tlsfeature-03.txt


The issue is not the OID, it is support in the browsers. If there is
support from one browser provider we can get backing to publish the
draft. Without implementation in at least one of the browsers it does
not help.




On Thu, Apr 24, 2014 at 3:55 PM, Klemens Baum <klemensbaum@gmail.com> wrote:
> After the whole Heartbleed incident, it has become obvious that the
> current mechanisms for Certificate Revocation are inadequately
> enforced by clients.
>
> To combat the issue, it would seem desirable for a security-conscious
> server operator to be able to require the use of OCSP stapling on a
> per-certificate basis. There was already an Internet-Draft (now
> expired) for an X.509v3 extension which would provide this feature:
> https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/
>
> Clients supporting the extension could display an enhanced security
> indicator (e.g. "Certificate Status: Not revoked") for certificates
> carrying the extension which pass validation, which would also
> motivate more widespread adoption of OCSP stapling in favor of CRLs
> and client-initiated OCSP requests.
>
> Since the draft looked very promising, I suggest that it should be
> unexpired. If anyone with the authority to do so agrees, please submit
> a request for resurrection per the guidelines at
> http://www.ietf.org/ietf-ftp/1id-guidelines.txt.
>
> A few minor clarifications may still be needed so that it can be
> quickly implemented by major browsers and the CAs:
>
> - The tls-feature OID is currently specified with a value of { id-pe 1
> }, which corresponds to 1.3.6.1.5.5.7.1.1 (authorityInfoAccess, itself
> already an X.509v3 extension). Surely a new OID in the
> pkix.privateExtension arc will need to be allocated by IANA and if
> this is the case, it should be noted in the section "IANA
> Considerations".
>
> Please share your opinions!



-- 
Website: http://hallambaker.com/