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.xml

    r1987 r1988  
    659659          </figure>
    660660
    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>
    663682<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>
    664683<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.