Changeset 1988
- Timestamp:
- 06/11/12 15:17:43 (10 years ago)
- Location:
- draft-ietf-httpbis-http2/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.html
r1986 r1988 1295 1295 </p> 1296 1296 <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. 1304 1303 </p> 1305 1304 <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, … … 2036 2035 <li><em>RFC4366</em> <a href="#RFC4366"><b>10</b></a></li> 2037 2036 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">3.2.3</a>, <a href="#RFC4559"><b>10</b></a></li> 2038 <li><em>RFC5246</em> <a href="#RFC5246"><b>10</b></a></li> 2037 <li><em>RFC5246</em> <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> <a href="#rfc.xref.RFC5246.1">2.6.9</a></li> 2039 </ul> 2040 </li> 2039 2041 <li><em>RFC6454</em> <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> 2040 2042 </ul> -
draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.xml
r1987 r1988 659 659 </figure> 660 660 661 <t>Slot: The index in the server's client certificate vector where this certificate should be stored. If there is already a certificate stored at this index, it will be overwritten. The index is one based, not zero based; zero is an invalid slot index.</t> 662 <t>Proof: Cryptographic proof that the client has possession of the private key associated with the certificate. The format is a TLS digitally-signed element (http://tools.ietf.org/html/rfc5246#section-4.7). The signature algorithm must be the same as that used in the CertificateVerify message. However, since the MD5+SHA1 signature type used in TLS 1.0 connections can not be correctly encoded in a digitally-signed element, SHA1 must be used when MD5+SHA1 was used in the SSL connection. The signature is calculated over a 32 byte TLS extractor value (http://tools.ietf.org/html/rfc5705) with a label of "EXPORTER SPDY certificate proof" using the empty string as context. ForRSA certificates the signature would 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 a 1024-bit RSA key, the CREDENTIAL message would be ~500 bytes.</t> 661 <t> 662 Slot: The index in the server's client certificate vector where this 663 certificate should be stored. If there is already a certificate stored at 664 this index, it will be overwritten. The index is one based, not zero based; 665 zero is an invalid slot index. 666 </t> 667 <t> 668 Proof: Cryptographic proof that the client has possession of the private key 669 associated with the certificate. The format is a TLS digitally-signed 670 element (<xref target="RFC5246" x:fmt="," x:sec="4.7"/>). The signature 671 algorithm must be the same as that used in the CertificateVerify message. 672 However, since the MD5+SHA1 signature type used in TLS 1.0 connections can 673 not be correctly encoded in a digitally-signed element, SHA1 must be used 674 when MD5+SHA1 was used in the SSL connection. The signature is calculated 675 over a 32 byte TLS extractor value (http://tools.ietf.org/html/rfc5705) with 676 a label of "EXPORTER SPDY certificate proof" using the empty string as 677 context. ForRSA certificates the signature would be a PKCS#1 v1.5 signature. 678 For ECDSA, it would be an ECDSA-Sig-Value 679 (http://tools.ietf.org/html/rfc5480#appendix-A). For a 1024-bit RSA key, 680 the CREDENTIAL message would be ~500 bytes. 681 </t> 663 682 <t>Certificate: The certificate chain, starting with the leaf certificate. Each certificate must be encoded as a 32 bit length, followed by a DER encoded certificate. The certificate must be of the same type (RSA, ECDSA, etc) as the client certificate associated with the SSL connection.</t> 664 683 <t>If the server receives a request for a resource with unacceptable credential (either missing or invalid), it must reply with a RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon receipt of a RST_STREAM frame with INVALID_CREDENTIALS, the client should initiate a new stream directly to the requested origin and resend the request. Note, SPDY does not allow the server to request different client authentication for different resources in the same origin.</t>
Note: See TracChangeset
for help on using the changeset viewer.