Ignore:
Timestamp:
06/11/12 15:17:43 (8 years ago)
Author:
julian.reschke@…
Message:

fix reference

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.html

    r1986 r1988  
    12951295      </p>
    12961296      <p id="rfc.section.2.6.9.p.6">Proof: Cryptographic proof that the client has possession of the private key associated with the certificate. The format is
    1297          a TLS digitally-signed element (http://tools.ietf.org/html/rfc5246#section-4.7). The signature algorithm must be the same
    1298          as that used in the CertificateVerify message. However, since the MD5+SHA1 signature type used in TLS 1.0 connections can
    1299          not be correctly encoded in a digitally-signed element, SHA1 must be used when MD5+SHA1 was used in the SSL connection. The
    1300          signature is calculated over a 32 byte TLS extractor value (http://tools.ietf.org/html/rfc5705) with a label of "EXPORTER
    1301          SPDY certificate proof" using the empty string as context. ForRSA certificates the signature would be a PKCS#1 v1.5 signature.
    1302          For ECDSA, it would be an ECDSA-Sig-Value (http://tools.ietf.org/html/rfc5480#appendix-A). For a 1024-bit RSA key, the CREDENTIAL
    1303          message would be ~500 bytes.
     1297         a TLS digitally-signed element (<a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>, <a href="http://tools.ietf.org/html/rfc5246#section-4.7">Section 4.7</a>). The signature algorithm must be the same as that used in the CertificateVerify message. However, since the MD5+SHA1 signature
     1298         type used in TLS 1.0 connections can not be correctly encoded in a digitally-signed element, SHA1 must be used when MD5+SHA1
     1299         was used in the SSL connection. The signature is calculated over a 32 byte TLS extractor value (http://tools.ietf.org/html/rfc5705)
     1300         with a label of "EXPORTER SPDY certificate proof" using the empty string as context. ForRSA certificates the signature would
     1301         be a PKCS#1 v1.5 signature. For ECDSA, it would be an ECDSA-Sig-Value (http://tools.ietf.org/html/rfc5480#appendix-A). For
     1302         a 1024-bit RSA key, the CREDENTIAL message would be ~500 bytes.
    13041303      </p>
    13051304      <p id="rfc.section.2.6.9.p.7">Certificate: The certificate chain, starting with the leaf certificate. Each certificate must be encoded as a 32 bit length,
     
    20362035                  <li><em>RFC4366</em>&nbsp;&nbsp;<a href="#RFC4366"><b>10</b></a></li>
    20372036                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">3.2.3</a>, <a href="#RFC4559"><b>10</b></a></li>
    2038                   <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#RFC5246"><b>10</b></a></li>
     2037                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.6.9</a>, <a href="#RFC5246"><b>10</b></a><ul>
     2038                        <li><em>Section 4.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.6.9</a></li>
     2039                     </ul>
     2040                  </li>
    20392041                  <li><em>RFC6454</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6454.1">2.6.4</a>, <a href="#rfc.xref.RFC6454.2">3.1</a>, <a href="#rfc.xref.RFC6454.3">3.3</a>, <a href="#rfc.xref.RFC6454.4">5.1</a>, <a href="#RFC6454"><b>10</b></a></li>
    20402042               </ul>
Note: See TracChangeset for help on using the changeset viewer.