Changeset 1988


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

fix reference

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

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