Subject: Re: [pkix] agenda topics?

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 1 Jul 2012 09:47:31 -0400

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 <[email-masked]> wrote:
> Folks,
>
> Please send requests for agenda time to Stefan and cc me.
>
> Thanks,
>
> Steve
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

-- 
Website: http://hallambaker.com/

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Jul 2012 00:20:16 +0200

A reminder to send agenda proposals for PKIX meeting in Vancouver to me
and Steve

/Stefan