Re: [TLS] OCSP must staple

Brian Smith <brian@briansmith.org> Thu, 05 June 2014 19:12 UTC

Return-Path: <brian@briansmith.org>
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 E5EB01A026E for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 12:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 EtquhnE4Cv66 for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 12:12:08 -0700 (PDT)
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A512F1A026F for <tls@ietf.org>; Thu, 5 Jun 2014 12:12:08 -0700 (PDT)
Received: by mail-qg0-f52.google.com with SMTP id a108so2363590qge.25 for <tls@ietf.org>; Thu, 05 Jun 2014 12:12: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O6o+Pe6ZMz2qe2PZdl7IDi84dv62P92qlyTXNYrO4iU=; b=PWBDUJt87bum41SNpUL4I3JPn3mobh5WB4lz4U5m+euMJ6TKGWmNEF4tZUz5WasjtY nIyK3nZeFvZatfF6lAY+UPUPM/6RhFYFU5Yl6SZEkMsWY4+FmDNHujSh8s8PzvUUT9E8 RG0vbdE7Uw3Q689QYqaKG0Td9wi2f09r5twbfbeSvl2e55qVJvoMDYHcoYFr1R4FA4fx 7iKovl/Vg09y3GoM/Wm05Oxg08WyXkFv4XWdp4lFJ1qTkVjZUGtU7GaJizs0thScgJjz Ty2gxU1t3fDotS0hFi2TPV8dcBk+MEUGVsPyLgsWfroasKa21pdrJjRWwcpAuoH/TVbu lkAA==
X-Gm-Message-State: ALoCoQkAPu2J0VZj7mVf7VWcdBj6lzYhA0o59IxlrXMZoBRvIN6bf7+bKLrFq1UTZcbn3gP0QPv4
MIME-Version: 1.0
X-Received: by 10.229.79.2 with SMTP id n2mr85114728qck.11.1401995521796; Thu, 05 Jun 2014 12:12:01 -0700 (PDT)
Received: by 10.224.201.193 with HTTP; Thu, 5 Jun 2014 12:12:01 -0700 (PDT)
In-Reply-To: <5390B1D6.5010105@nthpermutation.com>
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> <5390B1D6.5010105@nthpermutation.com>
Date: Thu, 5 Jun 2014 12:12:01 -0700
Message-ID: <CAFewVt6Pr8yjV8EbYLp1HQJfYMgq2LJMt4uQqZWKChR6p12Wtg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=001a1133a1a00df9a604fb1b85df
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uMlbd73RFcRUaQBkzQYdIGN0Q_4
Cc: "<tls@ietf.org>" <tls@ietf.org>
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 19:12:10 -0000

On Thu, Jun 5, 2014 at 11:07 AM, Michael StJohns <msj@nthpermutation.com>
wrote:

> 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.
>

I don't think it actually is transitive. That is why I was asking it to be
changed to be transitive. I guess either way the draft should be clarified
regarding this.

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

<snip>

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.
>

Right, we should avoid going against RFC 5280's  recommendation here, so I
don't think this is a reasonable option.

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.
>

Is it really significantly easier for CAs to add new certificate policies
compared to adding new certificate extensions? I could see how that could
be the case, but I think it would be good to hear from CAs about this.

I think one consideration is whether somebody that is operating an
externally-operated sub-CA using closed-source, slow-release-cycle software
(e.g. Microsoft's CA software) could implement the policy-based approach
without waiting for any patch/update from their vendor. If that is the
case, that would be a significant benefit of your (policy-OID-per-feature)
policy-based approach.

Cheers,
Brian