Re: [TLS] OCSP must staple

Brian Smith <> Thu, 05 June 2014 19:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E5EB01A026E for <>; Thu, 5 Jun 2014 12:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EtquhnE4Cv66 for <>; Thu, 5 Jun 2014 12:12:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A512F1A026F for <>; Thu, 5 Jun 2014 12:12:08 -0700 (PDT)
Received: by with SMTP id a108so2363590qge.25 for <>; Thu, 05 Jun 2014 12:12:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id n2mr85114728qck.11.1401995521796; Thu, 05 Jun 2014 12:12:01 -0700 (PDT)
Received: by with HTTP; Thu, 5 Jun 2014 12:12:01 -0700 (PDT)
In-Reply-To: <>
References: <> <097101cf7aa7$17f960a0$47ec21e0$> <> <> <> <> <>
Date: Thu, 5 Jun 2014 12:12:01 -0700
Message-ID: <>
From: Brian Smith <>
To: Michael StJohns <>
Content-Type: multipart/alternative; boundary=001a1133a1a00df9a604fb1b85df
Cc: "<>" <>
Subject: Re: [TLS] OCSP must staple
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jun 2014 19:12:10 -0000

On Thu, Jun 5, 2014 at 11:07 AM, Michael StJohns <>

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


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