Committed to connecting the world

  •  
wtisd

ITU-T work programme

Home : ITU-T Home : ITU-T Work Programme : H.810     
  ITU-T A.5 justification information for referenced document IETF RFC 2246 (1999) in draft H.810
1. Clear description of the referenced document:
Name: IETF RFC 2246 (1999)
Title: The TLS Protocol Version 1.0
2. Status of approval:
Standards track - Proposed Standard (1999-01) - Obsolete
3. Justification for the specific reference:
H.810 requires the use of TLS v1.0 for the operation of medical, health and fitness devices using the WAN interface specifically for its privacy cryptography for data encryption and its connection reliability and integrity using secure hash functions. The TLS v1.0 protocol provides sufficient communication privacy over the Internet allowing client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. There is also dependency on the use of this spec across other IHE and HL7 that also use this version of the TLS protocol.
4. Current information, if any, about IPR issues:
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=2246
5. Other useful information describing the "Quality" of the document:
RFC 2246 has been in existence since 1999. This is an IETF standards-track document that has been reviewed extensively in the IETF.
6. The degree of stability or maturity of the document:
RFC is a standards-track document and is currently in the "Proposed Standard" state. Obsoleted by RFC 4346. Updated by RFC 6176, RFC 3546, RFC 5746. Errata exist.
7. Relationship with other existing or emerging documents:
RFC 2246 is based on the SSL 3.0 published by Netscape and is widely used to provide security for electronic commerce. References within the listed RFCs are listed under item (8).
8. Any explicit references within that referenced document should also be listed:
[1] W. Tuchman, "Hellman Presents No Shortcut Solutions to DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41./
[2] Bleichenbacher D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1" in Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:1--12, 1998./
[3] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983./
[4] W. Diffie and M. E. Hellman, "New Directions in Cryptography," IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977, pp. 74-84./
[5] NIST FIPS PUB 186, "Digital Signature Standard," National Institute of Standards and Technology, U.S. Department of Commerce, May 18, 1994./
[6] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985./
[7] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996./
[8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC 2104, February 1997./
[9] X. Lai, "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992./
[10] Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319, April 1992./
[11] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992./
[12] RSA Laboratories, "PKCS #1: RSA Encryption Standard," version 1.5, November 1993./
[13] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax Standard," version 1.5, November 1993./
[14] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax Standard," version 1.5, November 1993./
[15] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC 2459, January 1999./
[16] Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, January 1998./
[17] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption Algorithm, Work in Progress./
[18] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126./
[19] Contact RSA Data Security, Inc., Tel: 415-595-8782/
[20] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C, Published by John Wiley & Sons, Inc. 1994./
[21] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, Work in Progress, May 31, 1994./
[22] Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995./
[23] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996./
[24] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, September 1981./
[25] Postel J., and J. Reynolds, "Telnet Protocol Specifications", STD 8, RFC 854, May 1993./
[26] Postel J., and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1993./
[27] ITU Recommendation X.509: "The Directory - Authentication Framework". 1988./
[28] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data Representation Standard, August 1995.
9. Qualification of ISOC/IETF:
9.1-9.6     Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).
9.7     The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.
9.8     Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
10. Other (for any supplementary information):
References should always be made to RFC numbers (and not by other designations such as STD, BCP, etc.). References not to be made to documents referred to as "Internet Drafts" or RFCs categorized as "Historic". Normative references should not be made to RFCs that are not standards, for example, "Informational" and "Experimental" RFCs.
Note: This form is based on Recommendation ITU-T A.5