RFC 6961 (TLS Multiple Certificate Status Extension)

has been published in June 2013; replace obsolete I-D reference.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1509098 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/mod/mod_ssl.html.en b/docs/manual/mod/mod_ssl.html.en
index 7033a6e3eb70824e05e7a08f0359ab87c154c14a..ca7b461713eadc153f0987f132e7ced707d845a3 100644 (file)
--- a/docs/manual/mod/mod_ssl.html.en
+++ b/docs/manual/mod/mod_ssl.html.en
@@ -2424,13 +2424,14 @@ for its own certificate in the TLS handshake. Configuring an
 prerequisite for enabling OCSP stapling.</p>
 
 <p>OCSP stapling relieves the client of querying the OCSP responder
-on its own, but it should be noted that in its current specification,
+on its own, but it should be noted that with the RFC 6066 specification,
 the server's <code>CertificateStatus</code> reply may only include an
 OCSP response for a single cert. For server certificates with intermediate
 CA certificates in their chain (the typical case nowadays),
-stapling in its current form therefore only partially achieves the
-stated goal of "saving roundtrips and resources" - see also the <a href="https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/">
-"Adding Multiple TLS Certificate Status Extension requests"</a> Internet draft.
+stapling in its current implementation therefore only partially achieves the
+stated goal of "saving roundtrips and resources" - see also
+<a href="http://www.ietf.org/rfc/rfc6961.txt">RFC 6961</a>
+(TLS Multiple Certificate Status Extension).
 </p>
 
 </div>

diff --git a/docs/manual/mod/mod_ssl.xml b/docs/manual/mod/mod_ssl.xml
index 19bd4a5cc0731ee16f1076353f82668a1fba3c7f..856a41c12aa4c969b297a283a9634e975d7bce5c 100644 (file)
--- a/docs/manual/mod/mod_ssl.xml
+++ b/docs/manual/mod/mod_ssl.xml
@@ -2281,14 +2281,14 @@ for its own certificate in the TLS handshake. Configuring an
 prerequisite for enabling OCSP stapling.</p>
 
 <p>OCSP stapling relieves the client of querying the OCSP responder
-on its own, but it should be noted that in its current specification,
+on its own, but it should be noted that with the RFC 6066 specification,
 the server's <code>CertificateStatus</code> reply may only include an
 OCSP response for a single cert. For server certificates with intermediate
 CA certificates in their chain (the typical case nowadays),
-stapling in its current form therefore only partially achieves the
-stated goal of "saving roundtrips and resources" - see also the <a
-href="https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/">
-"Adding Multiple TLS Certificate Status Extension requests"</a> Internet draft.
+stapling in its current implementation therefore only partially achieves the
+stated goal of "saving roundtrips and resources" - see also
+<a href="http://www.ietf.org/rfc/rfc6961.txt">RFC 6961</a>
+(TLS Multiple Certificate Status Extension).
 </p>
 </usage>
 </directivesynopsis>