Re: [TLS] OCSP must staple

Michael StJohns <msj@nthpermutation.com> Thu, 05 June 2014 18:07 UTC

Return-Path: <msj@nthpermutation.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 D2F681A0144 for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 11:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 UMjBb6BFQLEo for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 11:07:09 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A861A01A0 for <tls@ietf.org>; Thu, 5 Jun 2014 11:07:08 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id k15so1607110qaq.40 for <tls@ietf.org>; Thu, 05 Jun 2014 11:07:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K3ckpkFB1YvsLU4WUYOVN5tiK17oJCONuN+sj0KOfjM=; b=cz3Z2skxlI5s9vvjTiwGuaBQsMg19NgVj8tQcG74Mgop/IOn4tpE+GjqCjtz2DfMHn TRQUxg4j/Q2/c5zKRssBH1LKQCNsLAJH79WlvEeqVGrn7gFqrwccMFqc95Ua3/42/8Ct VvFU58rZU7J5A+pOHay6Hpe0kz6iSTUFaZoS1eDaWXRaf7LUIVkjou6AR5JJ+4wlQ1I2 9gh3TrQ3Lvk7TVuUsRz0dxQqDHp6ypTbumRWIrBAxta6wEFz7TrhgUWV37mPqUcg0wr9 zcEu6MV+OnSotnISzUknG9J/BiDzRCpIySLzY4QbOfRs921pnfaNZYT9xOW571XytvGa mrDQ==
X-Gm-Message-State: ALoCoQmVviH8GBHl2ghpBgOFUJpa8qyAr2DGAkW5C/hwMPuX03VYyCndNlhFQCUWUX4BGXYp1A9O
X-Received: by 10.224.166.73 with SMTP id l9mr19686542qay.34.1401991621737; Thu, 05 Jun 2014 11:07:01 -0700 (PDT)
Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id b7sm10528844qae.32.2014.06.05.11.07.01 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 11:07:01 -0700 (PDT)
Message-ID: <5390B1D6.5010105@nthpermutation.com>
Date: Thu, 05 Jun 2014 14:07:18 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <CAMm+LwgTnva9jJgVfkaOZ1qP0Rk3w-mFfepnubosgtrCEARv=g@mail.gmail.com> <539069CC.5010304@cs.tcd.ie>
In-Reply-To: <539069CC.5010304@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FeROtAFkt4ZjJJmqIMSX-7wRAcI
Subject: Re: [TLS] OCSP must staple
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: Thu, 05 Jun 2014 18:07:24 -0000

Hi -

The note by Brian Smith made me take a second look at 
http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/. From the 
list chatter, I thought it was pretty much a standard CA extension.  I 
didn't realize that PHB had defined it as a transitive (i.e. if the CA 
has it, then it applies all the way down the chain) extension, rather 
than just a simple one-off application.

Given the above, I would reject the document and suggest instead that 
this use the CertificatePolicies extension.

Two ways of doing this:

First:

1) Define a policy OID for each TLS feature - the set is pretty small 
right now and I don't see it growing all that much.  This is probably 
the right approach and doesn't require anything more than a description 
of the OID and the related policy processing.

or Second

1) Define a policy OID for TLS Features
2) Define a PolicyQualifier OID for a FeatureIds qualifier
3) Define "FeatureIds ::= SEQUENCE of TlsFeatures"
4) Define "TlsFeatures ::= INTEGER { feature1 (1), feature2(2), ...}

This is more flexible, but seems to violate the spirit of RFC5280, 
section 4.2.1.4 - the "RECOMMENDS" items.

Doing it one of the above ways doesn't require modification to the cert 
path building logic (which isn't fully specified in the draft and should 
be).  The first also - mostly - doesn't require changes to code that 
build certificates which means it could enter production on the cert 
side much quicker.

Mike



On 6/5/2014 8:59 AM, Stephen Farrell wrote:
> Hiya,
>
> On 05/06/14 13:40, Phillip Hallam-Baker wrote:
>> By which I simply mean, lets make get people to actually read that
>> particular draft rather than start a cabal. So if we give folks a week
>> and then we can go forward with the document shepherd?
> Sure works for me. Can you try recruit a shepherd?
>
> I'll do an AD review in any case before I start IETF LC and will
> post a copy of that here. If other folks have comments I guess
> send those here or to PHB and me. I'd be happy to get a couple
> of mails saying "read it, its ready" after Phill's done his
> tweaks as well btw.
>
> Cheers,
> S.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>