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/trunk@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 7991455fd8a483d86f091b2cab6fbb614ec8bc13..96ed2e1433a07144d960cefcac8c84dd1b417c9a 100644 (file)
--- a/docs/manual/mod/mod_ssl.html.en
+++ b/docs/manual/mod/mod_ssl.html.en
@@ -2420,13 +2420,13 @@ 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>.
 </p>
 
 </div>

diff --git a/docs/manual/mod/mod_ssl.xml b/docs/manual/mod/mod_ssl.xml
index 4032bdb8e02186e9a7bba99647446736c1bc6375..87a23e1eeeea0629e774f9a3d06aa912431149a7 100644 (file)
--- a/docs/manual/mod/mod_ssl.xml
+++ b/docs/manual/mod/mod_ssl.xml
@@ -2278,14 +2278,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>