Re: [pkix] agenda topics?
Phillip Hallam-Baker <hallam@gmail.com> Sun, 01 July 2012 13:47 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF81D21F8B71 for <pkix@ietfa.amsl.com>; Sun, 1 Jul 2012 06:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.473
X-Spam-Level:
X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbSKZmZDBo1r for <pkix@ietfa.amsl.com>; Sun, 1 Jul 2012 06:47:30 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11C0221F8B34 for <pkix@ietf.org>; Sun, 1 Jul 2012 06:47:29 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so7703857obb.31 for <pkix@ietf.org>; Sun, 01 Jul 2012 06:47:31 -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=NfCHxzaUWkvTN2CWDuyDCLlWbCNnLgqGDFcmCr1RnOs=; b=hz8JCOFb4J1ahSN0THINRS6jQWhPP/cvpuN9Kb6bZXyG6Y6uUTLQ2TTf7uU7X/kVMr 4VsAtDD6pKFX5/LLeAvLnKP5OwzlcKHNvOaPuCQyinqDycZoakL6KvB1FgWB8ndIMjy+ Da+AdZmxjy1I7LjnqyIzlQWda3SayXpjjngIWLA4ZQsfuIlhSETmgOrcfQC9AWq0FrO7 EsA0ncJcq9xGiVUW8mA5M/1MPyC5nYiwvjqRlsHr1XmgQdbQ8fnf5PO2cDtpsFVQeBLG oMziroWulwcVIyG0M6CNLtGg/WpFISWjYR4xP3BXSOe+nwFz1hMQBaBrRjF5zWDVoDiH LBcw==
MIME-Version: 1.0
Received: by 10.60.18.114 with SMTP id v18mr9669886oed.34.1341150451728; Sun, 01 Jul 2012 06:47:31 -0700 (PDT)
Received: by 10.182.64.166 with HTTP; Sun, 1 Jul 2012 06:47:31 -0700 (PDT)
In-Reply-To: <p06240803cc08e11b69a8@128.89.89.227>
References: <p06240803cc08e11b69a8@128.89.89.227>
Date: Sun, 01 Jul 2012 09:47:31 -0400
Message-ID: <CAMm+Lwh9SAVqyxiiw37m5xfU_wM5FvKC+PuGncZqbXbVCeQh3g@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: pkix@ietf.org
Subject: Re: [pkix] agenda topics?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Jul 2012 13:47:30 -0000
I would like to present: http://tools.ietf.org/html/draft-hallambaker-ocspdigest-00 We have discussed this in the past and the response was 'write a draft'. So here is a draft. The motivation for this extension is twofold: First it enables a better upgrade path for digest algorithm agility. A certificate signed with SHA1 can be 'endorsed' by an OCSP token with SHA2 or SHA3. This breaks a deployment deadlock issue that would otherwise make deployment of SHA1 infeasible due to the limited support for SHA2 in the deployed base. Second it enables a capability similar to Certificate Transparency but without the need to deploy a new infrastructure and without the direct client enforcement capability that Google's CT provides. The concern that drives both proposals is that DigiNotar was reporting the status of certificates that did not exist. The digest extension makes it possible for a third party to audit compliance with a requirement to distinguish between certificates known to have been issued and non-existent certificates. In the model I am anticipating, indirect client enforcement of the criteria would still be possible via either SCVP or the omnibroker protocol being developed: http://tools.ietf.org/html/draft-hallambaker-omnibroker-00 The transparency criteria is only relevant to authoritative OCSP responders being operated by CAs or their agents. Thus the inability of a CRL responder to support this feature is irrelevant as far as I am concerned. The choice for the group and the ADs is whether they want the feature developed in PKIX or elsewhere. I am quite happy discussing it in a new PKI extensions group or in CABForum as alternatives. Also note that doing the digest extension does not mean not doing Google's CT as well. But that is clearly going to take longer to deploy. SCVP was considered and rejected as a basis for the protocol as architecturally inappropriate. While SCVP and OCSP both appear to do the same thing they are actually designed for services to two different parties. OCSP is best suited for use by a CA publishing authoritative statements about the status of certificates. SCVP is best suited to implement a service that supports the client, providing trust statements that are relevant to the client's trust criteria. Since the objective here is to support authoritative status information, OCSP is the correct choice. On Thu, Jun 21, 2012 at 10:33 AM, Stephen Kent <kent@bbn.com> wrote: > Folks, > > Please send requests for agenda time to Stefan and cc me. > > Thanks, > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/
- [pkix] agenda topics? Stephen Kent
- Re: [pkix] agenda topics? Anders Rundgren
- Re: [pkix] agenda topics? Stephen Kent
- Re: [pkix] agenda topics? Anders Rundgren
- Re: [pkix] agenda topics? Paul Hoffman
- Re: [pkix] agenda topics? Anders Rundgren
- Re: [pkix] agenda topics? Phillip Hallam-Baker
- Re: [pkix] agenda topics? Stefan Santesson