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/