Skip to main content

Updates to Lightweight OCSP Profile for High Volume Environments
draft-ietf-lamps-rfc5019bis-12

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lamps-rfc5019bis@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, rfc-editor@rfc-editor.org, spasm@ietf.org
Subject: Protocol Action: 'Updates to Lightweight OCSP Profile for High Volume Environments' to Proposed Standard (draft-ietf-lamps-rfc5019bis-12.txt)

The IESG has approved the following document:
- 'Updates to Lightweight OCSP Profile for High Volume Environments'
  (draft-ietf-lamps-rfc5019bis-12.txt) as Proposed Standard

This document is the product of the Limited Additional Mechanisms for PKIX
and SMIME Working Group.

The IESG contact persons are Paul Wouters, Deb Cooley and Roman Danyliw.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5019bis/


Ballot Text

Technical Summary

   This specification defines a profile of the Online Certificate Status
   Protocol (OCSP) that addresses the scalability issues inherent when
   using OCSP in large scale (high volume) Public Key Infrastructure
   (PKI) environments and/or in PKI environments that require a
   lightweight solution to minimize communication bandwidth and client-
   side processing.

   This specification obsoletes RFC 5019.  The profile specified in RFC
   5019 has been updated to allow and recommend the use of SHA-256 over
   SHA-1.

Working Group Summary

   There is broad support in the LAMPS WG for this document.  WG Last Call
   included many implementers, and all of the issues that were raise were
   resolved quickly.

   One notable concern was raised during WG Last Call that should be highlighted.  This document includes:

~~~
    OCSP responders SHOULD NOT distribute OCSP responses that contain
    CertIDs that use SHA-1 if the OCSP responder has no clients that
    require the use of SHA-1.
~~~

   It is recognized that there is no obvious point in time when this will be
   true.  However, no one could offer a better criteria for stopping support
   for SHA-1, which everyone wants to do.

Document Quality

   OCSP is widely deployed.

Personnel

   The Document Shepherd for this document is Russ Housley. The Responsible
   Area Director is Roman Danyliw.

RFC Editor Note