rfc3688.The IETF XML Registry

网络安全管理员-中级工习题库+参考答案一、单选题（共49题，每题1分，共49分）1.使用漏洞库匹配的扫描方法，能发现（）。

A、未知的漏洞B、已知的漏洞C、自行设计的软件中的漏洞D、所有漏洞正确答案：B2.使用PGP安全邮件系统，不能保证发送信息的（）A、完整性B、真实性C、私密性D、免抵赖性正确答案：B3.当traceroute程序收到（）报文时，表示traceroute程序报文已经到达目的主机。

（）A、ICMP超时B、ICMP主机不可达C、ICMP端口不可达D、ICMP网络不可达正确答案：C4.三重DES是一种加强了的DES加密算法，它的有效密钥长度是DES算法的（）倍。

A、2B、3C、4D、5正确答案：B5.下面情景（）属于授权。

A、用户依照系统提示输入用户名和口令B、用户使用加密软件对自己编写的OFFICE文档进行加密，以阻止其他人得到这份拷贝后提到文档中的内容C、用户在网络上共享了自己编写的一份OFFICE文档，并设定哪些用户可以阅读，哪些用户可以修改D、某个人尝试登录到你的计算机中，但是口令输入的不对，系统提示口令错误，并将这次失败的登录过程记录在系统日志中正确答案：C6.应能够防护系统免受来自外部小型组织的、拥有少量资源的威胁源发起的恶意攻击、一般的自然灾难，所造成的重要资源损害，能够发现重要的安全漏洞和安全事件，在系统遭到损害后，能够在一段时间内恢复部分功能是几级要求。

（）A、一级B、四级C、三级D、二级正确答案：D7.Windows服务器主机应对文件系统实施保护，能实现这一要求的文件系统格式是（）。

A、FATB、FAT32C、NTFSD、FAT16正确答案：C8.隔离装置独有的SQL防护规则库在默认配置情况下，可以阻断所有对数据库的管理操作，严格禁止在外网进行数据库的管理维护操作。

以下不属于默认配置下禁止的操作有（）A、建立、修改、删除存储过程B、建立、修改、删除表空间C、建立、修改、删除配置策略D、建立、修改、删除用户正确答案：C9.具备最佳读写性能的RAID级别是（）。

本文翻译者：weicq2000RFC 6071 IP安全(IPsec)和互联网密钥交换(IKE)文件路线图(2011年2月)RFC 6071废止了RFC 2411。

摘要过去几年，定义和使用IP安全(IPsec)和互联网密钥交换(Internet Key Exchange, IKE)的RFCs数量急剧增长。

造成这种复杂情况的主要原因是这些RFCs源于许多IETF工作组：最初的IPsec 工作组，它的各种衍生组织，以及其他使用IPsec和/或IKE来保护它们的协议流量的工作组。

本文件归纳与IPsec和IKE有关的RFCs。

包括对每个RFC的简短描述，伴随背景信息介绍IPsec成长和扩展的动机及其来龙去脉。

本文件废止了RFC2411，先前的“IP安全文件路线图”。

[RFC-2411]简单描述各种等级基本IPsec文件的相互关系。

[RFC-2411]的要点是说明文件的建议内容，这些文件规定附加加密和认证算法。

本备忘录状态本文件不是互联网标准跟踪(Internet Standards Track)规范；出版它是出于提供信息目的。

本文件是互联网工程任务组(Internet Engineering Task Force, IETF)的作品。

它代表IETF 社会的共识。

它收到了公众评价并已获得互联网工程指导组(Internet Engineering Steering Group, IESG)认可和获准出版。

由IESG批准的文件不一定都是某个层次互联网标准的候选方案；参阅RFC5741第2章。

有关本文件目前状态信息，任何错误，以及如何得到有关它的反馈可以浏览：/info/rfc6071。

版权声明Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modifiedoutside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it intolanguages other than English.目录第1章序言第2章IPsec/IEK背景信息2-1 IPsec/IKE文件相互关系2-2 IPsec版本2-2-1 “旧”IPsec (IPsec-v2)和“新”IPsec (IPsec-v3)的不同2-3 IKE版本2-3-1 IKEv1和IKEv2的不同2-4 IPsec和IKE的IANA注册第3章IPsec文件3-1 基本文件3-1-1 “旧”IPsec (IPsec-v2)3-1-2 “新”IPsec (IPsec-v3)3-2 对IPsec的补充3-3 一般考虑第4章IKE文件4-1 基本文件4-1-1 IKEv14-1-2 IKEv24-2 补充和扩展4-2-1 对端认证方法4-2-2 证书内容和管理(PKI4IPsec)4-2-3 失效的对端检查4-2-4 远程访问第5章密码算法和套件5-1 算法要求5-2 加密算法5-3 完整性保护(认证)算法5-4 组合模式算法5-5 伪随机函数(PRFs)5-6 密码套件5-7 迪菲赫尔曼算法第6章多播的IPsec/IKE第7章IPsec/IKE派生物7-1 IPsec策略7-2 IPsec MIBs7-3 IP压缩( IPComp)7-4 有比没有好安全(BTNS)策略7-5 密钥的Kerberized互联网协商(KINK)7-6 IPsec安全远程访问(IPSRA)7-7 IPsec密钥信息资源记录(IPSECKEY)第8章使用IPsec/IKE的其他协议8-1 移动IP(MIPv4和MIPv6)8-2 开放最短路径优先(OSPF)8-3 主机标识协议(HIP)8-4 流控制传输协议(SCTP)8-5 茁壮首部压缩(ROHC)8-6 边界网关协议(BGP)8-7 IPsec 基准(测试)8-8 网络地址转换器(NAT)8-9 会话发起协议(SIP)8-10 显示分组灵敏度标签第9章其他采纳非IPsec功能IKE的协议9-1 可扩展认证协议(EAP)9-2 光纤通道9-3 无线安全第10章致谢第11章安全考虑第12章参考文献12-1 信息性参考文献附录A 算法要求等级归纳第1章序言互联网协议安全(Internet Protocol Security, IPsec)是一组协议，它在IP层对互联网通信提供安全保证。

中移动家庭网关终端技术规范vThe document was finally revised on 2021中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳家庭网关终端技术规范T e c h n i c a l S p e c i f i c a t i o n f o r H o m e版本号：╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施中国移动通信集团公司发布目录前言本标准明确了中国移动家庭网关需求，是家庭网关终端需要遵从的技术文件。

供中国移动内部和厂商共同使用，是实施家庭业务的依据之一。

本标准主要包括以下几方面内容：接口要求、功能要求、性能要求、网管和维护要求、软硬件系统要求以及运行环境等要求。

本标准是家庭网关设备系列标准之一，该系列标准的结构、名称或预计的名称如下：本标准需与《家庭网关业务技术规范》、《家庭网关业务技术规范—WLAN 共享分册》、《宜居通业务技术规范》、《家庭宽带类业务技术规范》、《家庭网关管理技术规范》、《宜居通终端技术规范》配套使用。

本标准的附录A、附录B为标准性附录。

本标准由中移号文件印发。

本标准由中国移动通信集团公司数据部提出，集团公司技术部归口。

本标准起草单位：中国移动通信研究院本标准主要起草人：张勇浩、梅海波、李建坤、刘聪、郭毅峰、陈心昕、黄薇、周丹、殷端、张彪、杨彦、刘松鹏、封栋梁、金波、叶朝阳1.范围本标准规定了中国移动家庭网关的设备形态、接口、功能、管理、安全、性能、运行环境、设备软硬件、基本应用和用户界面等要求，供中国移动通信集团内部使用，是开发研制接入型和宽带应用型家庭网关的技术依据。

本标准适用于2G/3G/4G移动网络、有线宽带网络环境。

2.规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。

凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。

中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳家庭网关终端技术规范T e c h n i c a l S p e c i f i c a t i o n f o r H o m e G a t e w a y版本号：3.0.0╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施目录1. 范围 (1)2. 规范性引用文件 (1)3. 术语、定义和缩略语 (5)4. 设备总体定义 (9)4.1.设备在网络中的位置 (9)4.2.接口定义 (10)4.3.设备类型 (10)5. 接入型家庭网关 (11)5.1.接口要求 (11)5.1.1. 网络侧接口 (11)5.1.1.1. 网络侧接口描述 (11)5.1.1.2. 网络侧以太网接口要求 (12)5.1.1.3. PON接口要求 (12)5.1.1.4. TD-SCDMA接口要求 (12)5.1.1.5. TD-LTE接口要求 (12)5.1.2. 用户侧接口 (12)5.1.2.1. 用户侧以太网接口要求 (12)5.1.2.2. WLAN接口 (12)5.1.2.3. USB接口（可选） (12)5.2.功能要求 (13)5.2.1. 数据通信要求 (13)5.2.1.1. IP协议要求 (13)5.2.1.2. 数据转发功能要求 (13)5.2.1.3. DNS功能要求 (14)5.2.1.4. IPv4地址管理及拨号管理功能要求 (14)5.2.1.5. IPv6地址管理及拨号管理功能要求 (16)5.2.1.6. IPv4 NAT要求 (16)5.2.1.7. ALG要求 (17)5.2.1.8. 组播要求 (17)5.2.1.9. 其他功能要求 (17)5.2.2. 安全要求 (17)5.2.2.1. 防火墙 (17)5.2.2.2. 登陆WEB页面的安全要求 (17)5.2.2.3. 设备安全性 (18)5.2.3. QoS 要求 (18)5.2.4. VLAN功能要求 (19)5.2.5. USB扩展及管理（可选） (19)5.2.6. 设备发现要求 (19)5.2.6.1. UPnP (19)5.2.6.2. DLNA（可选） (19)5.2.7.1. 支持WLAN的开启和禁用 (20)5.2.7.2. 基本要求 (20)5.2.7.3. 多SSID要求 (20)5.2.7.4. WLAN安全要求 (20)5.2.7.5. WLAN QoS要求 (21)5.2.7.6. WPS要求 (21)5.2.8. 基本应用要求 (22)5.2.8.1. WLAN共享 (22)5.2.8.2. 家庭存储（可选） (23)5.3.性能要求 (23)5.3.1. 路由转发性能要求 (23)5.3.1.1. 吞吐量 (23)5.3.1.2. 地址学习 (23)5.3.1.3. 缓存大小 (23)5.3.1.4. 连接数量要求 (24)5.3.2. WLAN无线性能要求 (24)5.3.2.1. WLAN吞吐量性能要求 (24)5.3.2.2. WLAN覆盖性能要求 (24)5.3.2.3. WLAN接收灵敏度要求 (24)5.4.管理和维护要求 (24)5.4.1. 本地管理和配置要求 (24)5.4.1.1. 本地管理基本要求 (24)5.4.1.2. 用户分级管理 (25)5.4.1.3. 系统信息管理 (25)5.4.1.4. 基本配置 (25)5.4.1.5. 高级配置 (26)5.4.1.6. 设备管理 (27)5.4.1.7. 网络诊断 (27)5.4.1.8. 设备认证注册功能 (27)5.4.2. 远程管理要求 (29)5.4.2.1. 远程管理基本要求 (30)5.4.2.2. 远程参数配置和性能监测 (30)5.4.2.3. 远程故障诊断功能 (30)5.4.2.4. 设备告警功能 (30)5.4.2.5. 远程链路维持功能 (31)5.4.2.6. 软件远程管理 (31)5.4.2.7. 业务部署和控制 (31)5.4.2.8. PON上行家庭网关远程管理实现方式 (31)5.4.3. 日志功能要求 (32)5.5.预配置要求 (33)5.5.1. 预配置要求 (33)5.6.硬件要求 (34)5.6.1. 基本要求 (34)5.6.3. 硬件基本框图示例 (34)5.7.软件要求 (34)5.7.1. 基本要求 (34)5.7.2. 软件基本架构 (35)5.7.3. 软件接口要求 (35)5.7.4. 用户登录要求 (36)5.7.5. 系统升级要求 (36)5.8.配置界面要求 (36)5.8.1. 配置界面要求 (36)5.8.2. 配置界面用户权限要求 (36)5.9.设备标识要求 (38)5.10.外观及附件要求 (39)5.10.1. 运营商Logo要求 (39)5.10.2. 设备标签要求 (39)5.10.3. 网关指示灯要求 (40)5.10.4. 开关与按键要求 (41)5.10.5. 设备面板标识要求 (41)5.10.6. 设备接口要求 (41)5.10.7. 附件要求 (41)5.11.运行环境要求 (42)5.11.1. 供电要求 (42)5.11.2. 环境要求 (42)5.11.3. 抗电磁干扰能力 (42)5.11.4. 设备本身产生的电磁干扰要求 (42)5.11.5. 过压过流保护 (42)5.12.认证要求 (43)6. 接入型家庭网关支持物联网功能 (43)6.1.接入型家庭网关支持宜居通的功能要求（内置433M模块） (43)6.1.1. 433M模块要求 (43)6.1.2. 外围设备要求 (43)6.1.3. 业务功能描述 (43)6.1.3.1. 安防功能要求 (44)6.1.3.2. 家电控制功能 (44)6.1.4. 接入型家庭网关配置界面要求 (45)6.1.4.1.配置界面要求 (45)6.1.4.2. 配置界面用户权限要求 (46)6.2.接入型家庭网关支持基于低功耗W I F I的物联网功能要求 (48)6.2.1. 设备接入功能要求 (48)6.2.1.1. WiFi接入 (48)6.2.1.1.1. 接入型家庭网关要求 (48)6.2.1.1.2. 外设要求 (49)6.2.1.2. DHCP流程要求 (49)7. 宽带应用型家庭网关 (49)7.1.类型描述 (49)7.2.分体机接入设备要求 (49)7.3.分体机应用设备（机顶盒）要求 (50)7.3.1. 硬件要求 (50)7.3.1.1. 硬件、接口及按键要求 (50)7.3.1.2. 遥控器要求及参考设计 (53)7.3.1.3. 电源要求 (53)7.3.1.4. 配件要求 (53)7.3.1.5. 设备标识要求 (53)7.3.2. 网络侧接口要求 (54)7.3.3. 业务功能要求 (54)7.3.3.1. 互联网电视应用 (54)7.3.3.2. 多屏互动功能 (54)7.3.3.2.1. 概述 (54)7.3.3.2.2. 镜像功能 (54)7.3.3.2.3. 分享功能 (55)7.3.3.3. 家庭高清视频通话（可选） (55)7.3.3.4. 家庭卡拉OK功能（可选） (56)7.3.3.5. 语音交互功能 (56)7.3.4. 软件要求 (56)7.3.4.1. 操作系统要求 (56)7.3.4.2. 软件协议要求 (57)7.3.4.3. 编码及解码能力要求 (57)7.3.4.3.1. 编解码能力要求 (57)7.3.4.3.2. 音视频播放质量要求 (58)7.3.4.4. 屏幕管理要求 (58)7.3.4.5. 防刷机要求 (58)7.3.5. 管理要求 (59)7.3.5.1. 操作管理 (59)7.3.5.2. 软件管理 (60)7.3.5.3. 文件管理 (60)7.3.5.4. 配置管理 (60)7.3.6. 其他要求 (61)7.3.6.1. 供电要求 (61)7.3.6.2. 环境要求 (61)7.3.6.3. 噪声要求 (62)7.4.一体机设备要求 (62)7.4.1. 网络侧接口要求 (62)7.4.2. 网络接入功能要求 (62)7.4.3. 业务功能要求 (62)7.4.4. 软件要求 (62)7.4.5. 管理要求 (62)7.4.6. 硬件要求 (62)7.4.7. 其他要求 (62)7.4.7.1. 供电要求 (62)7.4.7.2. 环境要求 (63)7.4.7.3. 噪声要求 (63)8. 编制历史 (63)附录A省公司代码 (64)附录B设备故障消息（标准性附录） (65)B.1 告警编号规则 (65)B.2 设备告警信息列表 (66)附录C WIMO协议说明 (67)C.1设备类型和功能流程 (67)C.2网络连接 (68)C.3设备连接 (69)C.4媒体格式要求 (70)C.4.1视频编解码流程 (70)C.4.2 M-JPEG视频编解码方案 (70)C.4.3 H.264视频编解码方案 (70)C.4.4 音频编解码流程 (70)附录D手机遥控接口说明 .............................................................................. 错误!未定义书签。

I. 简介在信息技术领域，标准的制定和遵循对于保障各类系统的稳定性和安全性至关重要。

其中，RFC（Request for Comments）标准是互联网工程任务组（IETF）制定的一系列文件，被广泛应用于互联网协议、技术规范和网络体系结构等方面。

RFC 8446标准是TLS（传输层安全性）协议的最新版本，本文将对该标准进行详细介绍。

II. TLS协议1. TLS概述TLS是一种安全协议，用于在互联网上传输数据。

它的主要目的是通过在通信双方之间建立安全的通道，保护数据的机密性和完整性，防止数据被窃取或篡改。

2. TLS的演进随着网络攻击技术的不断进步，TLS协议也在不断演进和升级。

RFC 8446标准就是TLS 1.3版本的规范文档，其前身是TLS 1.2，而TLS 1.0和TLS 1.1由于安全性漏洞已经被淘汰。

III. RFC 8446标准1. 发布背景RFC 8446标准于2018年8月发布，取代了TLS 1.2版本，并对之前的版本做出了一系列重大改进。

其发布旨在提高互联网数据通信的安全性和性能。

2. 主要特性RFC 8446标准在安全性和性能方面进行了多项改进，包括：- 强制使用Perfect Forward Secrecy（PFS）机制，防止密钥泄露后过去通信内容的解密。

- 精简握手流程，减少了握手时间和通信延迟，提高了通信效率。

- 支持更多的密码套件，提供更好的加密算法和安全性选项。

- 提供更好的抗攻击和防护机制，增强了通信的安全性。

- 支持0-RTT模式，进一步提高了通信速度。

IV. 对互联网的影响RFC 8446标准的发布对互联网的各个领域都有着积极的影响，具体体现在：1. 提高了通信的安全性和保密性。

RFC 8446标准的发布使得互联网数据通信的安全性得到了显著提升，能够更好地抵御各类网络攻击和数据窃取行为，有利于维护用户的隐私和利益。

2. 提升了通信的效率和性能。

RFC 8446标准的改进使得TLS协议的握手时间得到了显著缩短，通信延迟得到了一定程度的降低，为互联网数据传输提供了更加高效和快速的通道。

IIS短⽂件名漏洞复现图⽂详解⼀、漏洞描述此漏洞实际是由HTTP请求中旧DOS 8.3名称约定(SFN)的代字符(~)波浪号引起的。

它允许远程攻击者在Web根⽬录下公开⽂件和⽂件夹名称(不应该可被访问)。

攻击者可以找到通常⽆法从外部直接访问的重要⽂件,并获取有关应⽤程序基础结构的信息。

⼆、漏洞原理IIS的短⽂件名机制,可以暴⼒猜解短⽂件名,访问构造的某个存在的短⽂件名,会返回404,访问构造的某个不存在的短⽂件名,返回400。

漏洞成因:为了兼容16位MS-DOS程序,Windows为⽂件名较长的⽂件(和⽂件夹)⽣成了对应的windows 8.3短⽂件名。

在Windows下查看对应的短⽂件名,可以使⽤命令dir /x短⽂件名特征:1.只显⽰前6位的字符,后续字符⽤~1代替。

其中数字1是可以递增。

如果存在⽂件名类似的⽂件,则前⾯的6个字符是相同的,后⾯的数字进⾏递增2.后缀名最长只有3位,超过3位的会⽣成短⽂件名,且后缀多余的部分会截断。

3.所有⼩写字母均转换成⼤写的字母4.长⽂件名中包含多个”.”的时候,以⽂件最后⼀个”.”作为短⽂件名的后缀5.长⽂件名前缀/⽂件夹名字符长度符合0-9和A-Z、a-z范围且需要⼤于等于9位才会⽣成短⽂件名,如果包含空格或者其他部分特殊字符,不论长度均会⽣成短⽂件。

三、漏洞环境搭建及漏洞复现1、测试环境为windows server 2003 r2,开启webdav服务和net服务。

2、使⽤payload验证⽬标是否存在IIS短⽂件名漏洞,下图显⽰的404,说明⽬标存在该短⽂件名注:*可以匹配n个字符,n可以为03、浏览器访问⼀个不存在的短⽂件名,返回”Bad Request(400)”,说明⽬标不存在该短⽂件名4、通过浏览器访问上⾯两个payload,根据返回的结果,可以说明⽬标存在IIS短⽂件漏洞5、判断漏洞存在后,接下来⼿⼯详细分析猜解IIS短⽂件名原理5.1、在⽹站根⽬录(C:\Inetpub\wwwroot)下创建⼀个abcdef123456.txt⽂件5.3、通过以上两个图⽚,可以看出存在⼀个以a开头的短⽂件名5.7、⽤a-z的26个字母依次替换上述a的位置,当替换成t时,返回404页⾯,说明该短⽂件的第⼀位后缀是t5.8、按照上⾯的⽅法依次猜解得到该短⽂件名的后缀是txt5.9、到此为⽌,已经猜解出该短⽂件名为abcdef~1.txt6、根据已经猜解出来的短⽂件名abcdef~1.txt,继续猜解出该短⽂件名的完全⽂件名为abcdef123456.txt7、使⽤IIS短⽂件名扫描软件，获取⽬标存在哪些短⽂件名四、漏洞防御1、升级.net framework2、修改注册表键值：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem修改NtfsDisable8dot3NameCreation为1。

Internet Engineering Task Force (IETF) J. Reschke Request for Comments: 5987 greenbytes Category: Standards Track August 2010 ISSN: 2070-1721Character Set and Language Encoding forHypertext Transfer Protocol (HTTP) Header Field Parameters AbstractBy default, message header field parameters in Hypertext TransferProtocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. Thisdocument specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC2231.Status of This MemoThis is an Internet Standards Track document.This document is a product of the Internet Engineering Task Force(IETF). It represents the consensus of the IETF community. It hasreceived public review and has been approved for publication by theInternet Engineering Steering Group (IESG). Further information onInternet Standards is available in Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained at/info/rfc5987.Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.Reschke Standards Track [Page 1]Table of Contents1. Introduction (2)2. Notational Conventions (2)3. Comparison to RFC 2231 and Definition of the Encoding (3)3.1. Parameter Continuations (3)3.2. Parameter Value Character Set and Language Information (3)3.2.1. Definition (3)3.2.2. Examples (6)3.3. Language Specification in Encoded Words (6)4. Guidelines for Usage in HTTP Header Field Definitions (7)4.1. When to Use the Extension (7)4.2. Error Handling (7)5. Security Considerations (8)6. Acknowledgements (8)7. References (8)7.1. Normative References (8)7.2. Informative References (9)1. IntroductionBy default, message header field parameters in HTTP ([RFC2616])messages cannot carry characters outside the ISO-8859-1 character set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an encoding mechanismfor use in MIME headers. This document specifies an encodingsuitable for use in HTTP header fields that is compatible with aprofile of the encoding defined in RFC 2231.Note: in the remainder of this document, RFC 2231 is onlyreferenced for the purpose of explaining the choice of featuresthat were adopted; they are therefore purely informative.Note: this encoding does not apply to message payloads transmitted over HTTP, such as when using the media type "multipart/form-data" ([RFC2388]).2. Notational ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].This specification uses the ABNF (Augmented Backus-Naur Form)notation defined in [RFC5234]. The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP(linear whitespace).Reschke Standards Track [Page 2]Note that this specification uses the term "character set" forconsistency with other IETF specifications such as RFC 2277 (see[RFC2277], Section 3). A more accurate term would be "characterencoding" (a mapping of code points to octet sequences).3. Comparison to RFC 2231 and Definition of the EncodingRFC 2231 defines several extensions to MIME. The sections belowdiscuss if and how they apply to HTTP header fields.In short:o Parameter Continuations aren’t needed (Section 3.1),o Character Set and Language Information are useful, therefore asimple subset is specified (Section 3.2), ando Language Specifications in Encoded Words aren’t needed(Section 3.3).3.1. Parameter ContinuationsSection 3 of [RFC2231] defines a mechanism that deals with the length limitations that apply to MIME headers. These limitations do notapply to HTTP ([RFC2616], Section 19.4.7).Thus, parameter continuations are not part of the encoding defined by this specification.3.2. Parameter Value Character Set and Language InformationSection 4 of [RFC2231] specifies how to embed language informationinto parameter values, and also how to encode non-ASCII characters,dealing with restrictions both in MIME and HTTP header parameters.However, RFC 2231 does not specify a mandatory-to-implement character set, making it hard for senders to decide which character set to use. Thus, recipients implementing this specification MUST support thecharacter sets "ISO-8859-1" [ISO-8859-1] and "UTF-8" [RFC3629].Furthermore, RFC 2231 allows the character set information to be left out. The encoding defined by this specification does not allow that.3.2.1. DefinitionThe syntax for parameters is defined in Section 3.6 of [RFC2616](with RFC 2616 implied LWS translated to RFC 5234 LWSP):Reschke Standards Track [Page 3]parameter = attribute LWSP "=" LWSP valueattribute = tokenvalue = token / quoted-stringquoted-string = <quoted-string, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>In order to include character set and language information, thisspecification modifies the RFC 2616 grammar to be:parameter = reg-parameter / ext-parameterreg-parameter = parmname LWSP "=" LWSP valueext-parameter = parmname "*" LWSP "=" LWSP ext-valueparmname = 1*attr-charext-value = charset "’" [ language ] "’" value-chars; like RFC 2231’s <extended-initial-value>; (see [RFC2231], Section 7)charset = "UTF-8" / "ISO-8859-1" / mime-charsetmime-charset = 1*mime-charsetcmime-charsetc = ALPHA / DIGIT/ "!" / "#" / "$" / "%" / "&"/ "+" / "-" / "^" / "_" / "‘"/ "{" / "}" / "˜"; as <mime-charset> in Section 2.3 of [RFC2978]; except that the single quote is not included; SHOULD be registered in the IANA charset registrylanguage = <Language-Tag, defined in [RFC5646], Section 2.1>value-chars = *( pct-encoded / attr-char )pct-encoded = "%" HEXDIG HEXDIG; see [RFC3986], Section 2.1attr-char = ALPHA / DIGIT/ "!" / "#" / "$" / "&" / "+" / "-" / "."/ "^" / "_" / "‘" / "|" / "˜"; token except ( "*" / "’" / "%" )Reschke Standards Track [Page 4]Thus, a parameter is either a regular parameter (reg-parameter), aspreviously defined in Section 3.6 of [RFC2616], or an extendedparameter (ext-parameter).Extended parameters are those where the left-hand side of theassignment ends with an asterisk character.The value part of an extended parameter (ext-value) is a token thatconsists of three parts: the REQUIRED character set name (charset),the OPTIONAL language information (language), and a charactersequence representing the actual value (value-chars), separated bysingle quote characters. Note that both character set names andlanguage tags are restricted to the US-ASCII character set, and arematched case-insensitively (see [RFC2978], Section 2.3 and [RFC5646], Section 2.1.1).Inside the value part, characters not contained in attr-char areencoded into an octet sequence using the specified character set.That octet sequence is then percent-encoded as specified in Section2.1 of [RFC3986].Producers MUST use either the "UTF-8" ([RFC3629]) or the "ISO-8859-1" ([ISO-8859-1]) character set. Extension character sets (mime-charset) are reserved for future use.Note: recipients should be prepared to handle encoding errors,such as malformed or incomplete percent escape sequences, or non- decodable octet sequences, in a robust manner. This specification does not mandate any specific behavior, for instance, thefollowing strategies are all acceptable:* ignoring the parameter,* stripping a non-decodable octet sequence,* substituting a non-decodable octet sequence by a replacementcharacter, such as the Unicode character U+FFFD (ReplacementCharacter).Note: the RFC 2616 token production ([RFC2616], Section 2.2)differs from the production used in RFC 2231 (imported fromSection 5.1 of [RFC2045]) in that curly braces ("{" and "}") areexcluded. Thus, these two characters are excluded from the attr- char production as well.Reschke Standards Track [Page 5]Note: the <mime-charset> ABNF defined here differs from the one in Section 2.3 of [RFC2978] in that it does not allow the singlequote character (see also RFC Errata ID 1912 [Err1912]). Inpractice, no character set names using that character have beenregistered at the time of this writing.3.2.2. ExamplesNon-extended notation, using "token":foo: bar; title=EconomyNon-extended notation, using "quoted-string":foo: bar; title="US-$ rates"Extended notation, using the Unicode character U+00A3 (POUND SIGN):foo: bar; title*=iso-8859-1’en’%A3%20ratesNote: the Unicode pound sign character U+00A3 was encoded into thesingle octet A3 using the ISO-8859-1 character encoding, thenpercent-encoded. Also, note that the space character was encoded as %20, as it is not contained in attr-char.Extended notation, using the Unicode characters U+00A3 (POUND SIGN)and U+20AC (EURO SIGN):foo: bar; title*=UTF-8’’%c2%a3%20and%20%e2%82%ac%20ratesNote: the Unicode pound sign character U+00A3 was encoded into theoctet sequence C2 A3 using the UTF-8 character encoding, thenpercent-encoded. Likewise, the Unicode euro sign character U+20ACwas encoded into the octet sequence E2 82 AC, then percent-encoded.Also note that HEXDIG allows both lowercase and uppercase characters, so recipients must understand both, and that the language information is optional, while the character set is not.3.3. Language Specification in Encoded WordsSection 5 of [RFC2231] extends the encoding defined in [RFC2047] toalso support language specification in encoded words. Although theHTTP/1.1 specification does refer to RFC 2047 ([RFC2616], Section2.2), it’s not clear to which header field exactly it applies, andwhether it is implemented in practice (see</wg/httpbis/trac/ticket/111> for details).Thus, this specification does not include this feature.Reschke Standards Track [Page 6]4. Guidelines for Usage in HTTP Header Field DefinitionsSpecifications of HTTP header fields that use the extensions defined in Section 3.2 ought to clearly state that. A simple way to achieve this is to normatively reference this specification, and to includethe ext-value production into the ABNF for that header field.For instance:foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-paramtitle-param = "title" LWSP "=" LWSP value/ "title*" LWSP "=" LWSP ext-valueext-value = <see RFC 5987, Section 3.2>Note: The Parameter Value Continuation feature defined in Section 3 of [RFC2231] makes it impossible to have multiple instances ofextended parameters with identical parmname components, as theprocessing of continuations would become ambiguous. Thus,specifications using this extension are advised to disallow thiscase for compatibility with RFC 2231.4.1. When to Use the ExtensionSection 4.2 of [RFC2277] requires that protocol elements containinghuman-readable text are able to carry language information. Thus,the ext-value production ought to be always used when the parametervalue is of textual nature and its language is known.Furthermore, the extension ought to also be used whenever theparameter value needs to carry characters not present in the US-ASCII ([USASCII]) character set (note that it would be unacceptable todefine a new parameter that would be restricted to a subset of theUnicode character set).4.2. Error HandlingHeader field specifications need to define whether multiple instances of parameters with identical parmname components are allowed, and how they should be processed. This specification suggests that aparameter using the extended syntax takes precedence. This wouldallow producers to use both formats without breaking recipients that do not understand the extended syntax yet.Example:foo: bar; title="EURO exchange rates";title*=utf-8’’%e2%82%ac%20exchange%20ratesReschke Standards Track [Page 7]In this case, the sender provides an ASCII version of the title forlegacy recipients, but also includes an internationalized version for recipients understanding this specification -- the latter obviouslyought to prefer the new syntax over the old one.Note: at the time of this writing, many implementations failed to ignore the form they do not understand, or prioritize the ASCIIform although the extended syntax was present.5. Security ConsiderationsThe format described in this document makes it possible to transport non-ASCII characters, and thus enables character "spoofing"scenarios, in which a displayed value appears to be something otherthan it is.Furthermore, there are known attack scenarios relating to decodingUTF-8.See Section 10 of [RFC3629] for more information on both topics.In addition, the extension specified in this document makes itpossible to transport multiple language variants for a singleparameter, and such use might allow spoofing attacks, where different language versions of the same parameter are not equivalent. Whether this attack is useful as an attack depends on the parameterspecified.6. AcknowledgementsThanks to Martin Duerst and Frank Ellermann for help figuring outABNF details, to Graham Klyne and Alexey Melnikov for general review, to Chris Newman for pointing out an RFC 2231 incompatibility, and to Benjamin Carlyle and Roar Lauritzsen for implementer’s feedback.7. References7.1. Normative References[ISO-8859-1] International Organization for Standardization,"Information technology -- 8-bit single-byte codedgraphic character sets -- Part 1: Latin alphabet No.1", ISO/IEC 8859-1:1998, 1998.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997. Reschke Standards Track [Page 8][RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.[RFC2978] Freed, N. and J. Postel, "IANA Charset RegistrationProcedures", BCP 19, RFC 2978, October 2000.[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646", RFC 3629, STD 63, November 2003.[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,"Uniform Resource Identifier (URI): Generic Syntax",RFC 3986, STD 66, January 2005.[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF forSyntax Specifications: ABNF", STD 68, RFC 5234,January 2008.[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags forIdentifying Languages", BCP 47, RFC 5646,September 2009.[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for InformationInterchange", ANSI X3.4, 1986.7.2. Informative References[Err1912] RFC Errata, Errata ID 1912, RFC 2978,<>.[RFC2045] Freed, N. and N. Borenstein, "Multipurpose InternetMail Extensions (MIME) Part One: Format of InternetMessage Bodies", RFC 2045, November 1996.[RFC2047] Moore, K., "MIME (Multipurpose Internet MailExtensions) Part Three: Message Header Extensions forNon-ASCII Text", RFC 2047, November 1996.[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value andEncoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.[RFC2277] Alvestrand, H., "IETF Policy on Character Sets andLanguages", BCP 18, RFC 2277, January 1998.[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.Reschke Standards Track [Page 9]Author’s AddressJulian F. Reschkegreenbytes GmbHHafenweg 16Muenster, NW 48155GermanyEMail: julian.reschke@greenbytes.deURI: http://greenbytes.de/tech/webdav/Reschke Standards Track [Page 10]。

Network Working Group J. Galbraith Request for Comments: 4716 VanDyke Software Category: Informational R. Thayer Canola & Jones November 2006 The Secure Shell (SSH) Public Key File FormatStatus of This MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The IETF Trust (2006).AbstractThis document formally documents an existing public key file formatin use for exchanging public keys between different Secure Shell(SSH) implementations.In addition, this document defines a standard textual representation for SSH public key fingerprints.Table of Contents1. Introduction (2)2. Conventions Used in This Document (2)3. Key File Format (2)3.1. Line Termination Characters (2)3.2. Begin and End Markers (3)3.3. Key File Header (3)3.3.1. Subject Header (3)3.3.2. Comment Header (4)3.3.3. Private Use Headers (4)3.4. Public Key File Body (4)3.5. Differences with RFC 1421 PEM Formats (4)3.6. Examples (5)4. Public Key Fingerprints (6)5. IANA Considerations (6)6. Security Considerations (7)7. References (8)7.1. Normative References (8)7.2. Informative References (8)Galbraith & Thayer Informational [Page 1]1. IntroductionThe SSH protocol supports the use of public/private key pairs inorder to perform authentication based on public key cryptography.However, in order to use public key authentication in the SSHprotocol, public keys must first be exchanged between client andserver.This document formally describes an existing public key file formatthat can be used with any of the common existing file transfermechanisms in order to exchange public keys.The SSH protocol also uses public/private key pairs to authenticatethe server. In this scenario, it is important to verify that thepublic key provided by the server is indeed the server’s public key. This document describes a mechanism for creating a short text string that uniquely represents a particular public key, calledfingerprinting.2. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].3. Key File FormatIn order to implement public key authentication, SSH implementations must share public key files between the client and the server inorder to interoperate.A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 8-bit bytes excluding linetermination characters.3.1. Line Termination CharactersImplementations SHOULD generate public key files using their system’s local text file representation.In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of thecommon line termination sequence, <CR>, <LF>, or <CR><LF>.Galbraith & Thayer Informational [Page 2]3.2. Begin and End MarkersThe first line of a conforming key file MUST be a begin marker, which is the literal text:---- BEGIN SSH2 PUBLIC KEY ----The last line of a conforming key file MUST be an end marker, whichis the literal text:---- END SSH2 PUBLIC KEY ----3.3. Key File HeaderThe key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format:Header-tag ’:’ ’ ’ Header-valueThe Header-tag MUST NOT be more than 64 8-bit bytes and is case-insensitive. The Header-value MUST NOT be more than 1024 8-bitbytes. Each line in the header MUST NOT be more than 72 8-bit bytes.A line is continued if the last character in the line is a ’\’. Ifthe last character of a line is a ’\’, then the logical contents ofthe line are formed by removing the ’\’ and the line terminationcharacters, and appending the contents of the next line.The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be encoded in UTF-8 [RFC3629].A line that is not a continuation line that has no ’:’ in it is thefirst line of the base64-encoded body. (See Section 3.4.)The space of header-tags is managed as described in Section 5.Compliant implementations MUST ignore headers with unrecognizedheader-tags. Implementations SHOULD preserve such unrecognizedheaders when manipulating the key file.3.3.1. Subject HeaderThis field is used to store the login-name that the key was generated under. For example:Subject: userGalbraith & Thayer Informational [Page 3]3.3.2. Comment HeaderThe comment header contains a user-specified comment. The commentSHOULD be displayed when using the key.It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example:Comment: user@Currently, common practice is to quote the Header-value of theComment by prefixing and suffixing it with ’"’ characters, and someexisting implementations fail if these quotation marks are omitted.Compliant implementations MUST function correctly if the quotationmarks are omitted.Implementations MAY include the quotation marks. If the first andlast characters of the Header-value are matching quotation marks,implementations SHOULD remove them before using the value.3.3.3. Private Use HeadersHeaders with header-tags beginning with "x-" are reserved for private use.3.4. Public Key File BodyThe body of a public key file is the base64 encoded ([RFC2045])public key data as specified by [RFC4253], Section 6.6:string certificate or public key format identifierbyte[n] key/certificate dataAs with all other lines, each line in the body MUST NOT be longerthan 72 8-bit bytes excluding line termination characters.3.5. Differences with RFC 1421 PEM FormatsImplementers should take care to notice that while the format issuperficially similar to those specified by PEM [RFC1421] and OpenPGP [RFC2440], it is not identical; most notably:o The other specifications use different BEGIN/END delimiters (five dashes, no space rather than four dashes and a space).o There is no blank line before the start of the base64-encodedcontents.Galbraith & Thayer Informational [Page 4]o There is no Cyclic Redundancy Check (CRC) at the end of thebase64-encoded block.o Header continuation uses a backslash at the end of the continuedline rather than whitespace at the start of the next line.3.6. ExamplesThe following are some examples of public key files that arecompliant (note that the examples all wrap before 72 bytes to meetIETF document requirements; however, they are still compliant.)---- BEGIN SSH2 PUBLIC KEY ----Comment: "1024-bit RSA, converted from OpenSSH by me@"x-command: /home/me/bin/lock-in-guest.shAAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE=---- END SSH2 PUBLIC KEY -------- BEGIN SSH2 PUBLIC KEY ----Comment: This is my public key for use on \servers which I don’t like.AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV---- END SSH2 PUBLIC KEY -------- BEGIN SSH2 PUBLIC KEY ----Comment: DSA Public Key for use with MyIspAAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV---- END SSH2 PUBLIC KEY ----Galbraith & Thayer Informational [Page 5]---- BEGIN SSH2 PUBLIC KEY ----Subject: meComment: 1024-bit rsa, created by me@ Mon Jan 15 \08:31:24 2001AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0=---- END SSH2 PUBLIC KEY ----4. Public Key FingerprintsThe security of the SSH protocols relies on the verification ofpublic host keys. Since public keys tend to be very large, it isdifficult for a human to verify an entire host key. Even with aPublic Key Infrastructure (PKI) in place, it is useful to have astandard for exchanging short fingerprints of public keys.This section formally describes the method of generating public keyfingerprints that is in common use in the SSH community.The fingerprint of a public key consists of the output of the MD5message-digest algorithm [RFC1321]. The input to the algorithm isthe public key data as specified by [RFC4253]. (This is the samedata that is base64 encoded to form the body of the public key file.)The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons.For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87"5. IANA ConsiderationsSection 3.3 defines a new namespace of "Header-tags". These areUS-ASCII strings of maximum length 64 characters and arecase-insensitive.IANA has created and maintains a registry of these header-tags. The registry maps each header-tag to a reference defining the header.The initial contents of the registry are as follows:subject defined in Section 3.3.1comment defined in Section 3.3.2Header-tags beginning with "x-" are reserved for private use, asdefined in [RFC2434].Galbraith & Thayer Informational [Page 6]All other allocations are to be made by IETF consensus, as defined in [RFC2434].6. Security ConsiderationsThe file format described by this document provides no mechanism toverify the integrity or otherwise detect tampering with the datastored in such files. Given the potential of adversarial tamperingwith this data, system-specific measures (e.g., Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory AccessControls) SHOULD be used to protect these files. Also, if thecontents of these files are transferred it SHOULD be done over atrusted channel.The header data allowed by this file format could contain anunlimited range of information. While in many environments theinformation conveyed by this header data may be considered innocuous public information, it may constitute a channel through whichinformation about a user, a key, or its use may be disclosedintentionally or otherwise (e.g., "Comment: Mary E. Jones, 123 MainSt, Home Phone:..."). The presence and use of this header dataSHOULD be reviewed by sites that deploy this file format.The public key fingerprint method presented here relies on the MD5one-way hash function, which is known to have certain weaknessesregarding its collision resistance; however, the particular use made of MD5 here depends solely on its 2nd-preimage resistance, not on its collision resistance.MD5 is used here for historical reasons.Galbraith & Thayer Informational [Page 7]7. References7.1. Normative References[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet MailExtensions (MIME) Part One: Format of Internet MessageBodies", RFC 2045, November 1996.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646", STD 63, RFC 3629, November 2003.[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)Transport Layer Protocol", RFC 4253, January 2006.[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 2434,October 1998.7.2. Informative References[RFC1421] Linn, J., "Privacy Enhancement for Internet ElectronicMail: Part I: Message Encryption and AuthenticationProcedures", RFC 1421, February 1993.[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,"OpenPGP Message Format", RFC 2440, November 1998.Galbraith & Thayer Informational [Page 8]Authors’ AddressesJoseph GalbraithVanDyke Software4848 Tramway Ridge BlvdSuite 101Albuquerque, NM 87111USPhone: +1 505 332 5700EMail: galb@Rodney ThayerCanola & Jones650 Castro Street Suite 120-205Mountain View CA 94041USPhone: +1 650 704 8389EMail: rodney@Galbraith & Thayer Informational [Page 9]Full Copyright StatementCopyright (C) The IETF Trust (2006).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THATTHE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE.Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF atietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Galbraith & Thayer Informational [Page 10]。