Internet Engineering Task Force (IETF) N. Mavrogiannopoulos
Request for Comments: 6091 KUL
Obsoletes: 5081 D. Gillmor
Category: Informational Independent
ISSN: 2070-1721 February 2011
Internet Engineering Task Force (IETF) N. Mavrogiannopoulos
Request for Comments: 6091 KUL
Obsoletes: 5081 D. Gillmor
Category: Informational Independent
ISSN: 2070-1721 February 2011
Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
使用OpenPGP密钥进行传输层安全（TLS）身份验证
Abstract
摘要
This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types.
此备忘录定义了传输层安全性（TLS）扩展和相关语义，允许客户端和服务器协商TLS会话中OpenPGP证书的使用，并指定如何通过TLS传输OpenPGP证书。它还定义了非X.509证书类型的注册表。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6091.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6091.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Changes to the Handshake Message Contents .......................3
3.1. Client Hello ...............................................3
3.2. Server Hello ...............................................4
3.3. Server Certificate .........................................4
3.4. Certificate Request ........................................6
3.5. Client Certificate .........................................6
3.6. Other Handshake Messages ...................................7
4. Security Considerations .........................................7
5. IANA Considerations .............................................7
6. Acknowledgements ................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................8
Appendix A. Changes from RFC 5081 .................................9
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Changes to the Handshake Message Contents .......................3
3.1. Client Hello ...............................................3
3.2. Server Hello ...............................................4
3.3. Server Certificate .........................................4
3.4. Certificate Request ........................................6
3.5. Client Certificate .........................................6
3.6. Other Handshake Messages ...................................7
4. Security Considerations .........................................7
5. IANA Considerations .............................................7
6. Acknowledgements ................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................8
Appendix A. Changes from RFC 5081 .................................9
The IETF has two sets of standards for public key certificates: one set for the use of X.509 certificates [RFC5280], and one for OpenPGP certificates [RFC4880]. At the time of this writing, TLS [RFC5246] standards are defined to use X.509 certificates. This document specifies a way to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. The proposed extensions are backward-compatible with the current TLS specification, so that existing client and server implementations that make use of X.509 certificates are not affected.
IETF有两套公钥证书标准：一套用于使用X.509证书[RFC5280]，一套用于OpenPGP证书[RFC4880]。在撰写本文时，TLS[RFC5246]标准被定义为使用X.509证书。本文档指定了为TLS会话协商使用OpenPGP证书的方法，并指定了如何通过TLS传输OpenPGP证书。建议的扩展与当前的TLS规范向后兼容，因此使用X.509证书的现有客户端和服务器实现不会受到影响。
These extensions are not backward-compatible with [RFC5081], and the major differences are summarized in Appendix A. Although the OpenPGP CertificateType value is being reused by this memo with the same number as that specified in [RFC5081] but with different semantics, we believe that this causes no interoperability issues because the latter was not widely deployed.
这些扩展与[RFC5081]不向后兼容，主要差异在附录A中进行了总结。尽管OpenPGP CertificateType值被本备忘录重用，其编号与[RFC5081]中规定的编号相同，但语义不同，我们认为，这不会导致互操作性问题，因为后者没有得到广泛部署。
The term "OpenPGP key" is used in this document as in the OpenPGP specification [RFC4880]. We use the term "OpenPGP certificate" to refer to OpenPGP keys that are enabled for authentication.
本文件中使用的术语“OpenPGP密钥”与OpenPGP规范[RFC4880]中的术语相同。我们使用术语“OpenPGP证书”来指代启用身份验证的OpenPGP密钥。
This document uses the same notation and terminology used in the TLS Protocol specification [RFC5246].
本文件使用TLS协议规范[RFC5246]中使用的相同符号和术语。
The 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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section describes the changes to the TLS handshake message contents when OpenPGP certificates are to be used for authentication.
本节描述在使用OpenPGP证书进行身份验证时对TLS握手消息内容的更改。
In order to indicate the support of multiple certificate types, clients MUST include an extension of type "cert_type" to the extended client hello message. The "cert_type" TLS extension is assigned the value of 9 from the TLS ExtensionType registry. This value is used as the extension number for the extensions in both the client hello message and the server hello message. The hello extension mechanism is described in [RFC5246].
为了指示支持多种证书类型，客户端必须在扩展客户端hello消息中包含“cert_type”类型的扩展。“cert_type”TLS扩展从TLS ExtensionType注册表中分配值9。此值用作客户端hello消息和服务器hello消息中扩展的扩展编号。[RFC5246]中描述了hello扩展机制。
This extension carries a list of supported certificate types the client can use, sorted by client preference. This extension MUST be omitted if the client only supports X.509 certificates. The "extension_data" field of this extension contains a CertificateTypeExtension structure. Note that the CertificateTypeExtension structure is being used both by the client and the server, even though the structure is only specified once in this document. Reusing a single specification for both client and server is common in other specifications, such as the TLS protocol itself [RFC5246].
此扩展包含客户端可以使用的受支持证书类型列表，按客户端首选项排序。如果客户端仅支持X.509证书，则必须省略此扩展。此扩展的“extension_data”字段包含CertificateTypeExtension结构。请注意，客户机和服务器都在使用CertificateTypeExtension结构，即使该结构在本文档中只指定了一次。在其他规范中，例如TLS协议本身[RFC5246]，对客户端和服务器重复使用单个规范是很常见的。
enum { client, server } ClientOrServerExtension;
enum { client, server } ClientOrServerExtension;
enum { X.509(0), OpenPGP(1), (255) } CertificateType;
enum { X.509(0), OpenPGP(1), (255) } CertificateType;
struct {
select(ClientOrServerExtension) {
case client:
CertificateType certificate_types<1..2^8-1>;
case server:
CertificateType certificate_type;
}
} CertificateTypeExtension;
struct {
select(ClientOrServerExtension) {
case client:
CertificateType certificate_types<1..2^8-1>;
case server:
CertificateType certificate_type;
}
} CertificateTypeExtension;
No new cipher suites are required to use OpenPGP certificates. All existing cipher suites that support a key exchange method compatible with the key in the certificate can be used in combination with OpenPGP certificates.
使用OpenPGP证书不需要新的密码套件。所有支持与证书中的密钥兼容的密钥交换方法的现有密码套件都可以与OpenPGP证书结合使用。
If the server receives a client hello that contains the "cert_type" extension and chooses a cipher suite that requires a certificate, then two outcomes are possible. The server MUST either select a certificate type from the certificate_types field in the extended client hello or terminate the session with a fatal alert of type "unsupported_certificate".
如果服务器接收到一个包含“cert_type”扩展名的客户机hello，并选择了一个需要证书的密码套件，则可能出现两种结果。服务器必须从扩展客户端hello中的certificate_types字段中选择证书类型，或者使用类型为“unsupported_certificate”的致命警报终止会话。
The certificate type selected by the server is encoded in a CertificateTypeExtension structure, which is included in the extended server hello message using an extension of type "cert_type". Servers that only support X.509 certificates MAY omit including the "cert_type" extension in the extended server hello.
服务器选择的证书类型编码在CertificateTypeExtension结构中，该结构使用类型为“cert_type”的扩展包含在扩展服务器hello消息中。仅支持X.509证书的服务器可能会忽略在扩展服务器hello中包含“cert_type”扩展。
The contents of the certificate message sent from server to client and vice versa are determined by the negotiated certificate type and the selected cipher suite's key exchange algorithm.
从服务器发送到客户端（反之亦然）的证书消息的内容由协商的证书类型和所选密码套件的密钥交换算法决定。
If the OpenPGP certificate type is negotiated, then it is required to present an OpenPGP certificate in the certificate message. The certificate must contain a public key that matches the selected key exchange algorithm, as shown below.
如果协商了OpenPGP证书类型，则需要在证书消息中提供OpenPGP证书。证书必须包含与所选密钥交换算法匹配的公钥，如下所示。
Key Exchange Algorithm OpenPGP Certificate Type
密钥交换算法OpenPGP证书类型
RSA RSA public key that can be used for encryption.
可用于加密的RSA公钥。
DHE_DSS DSA public key that can be used for authentication.
可用于身份验证的DHE_DSS DSA公钥。
DHE_RSA RSA public key that can be used for authentication.
可用于身份验证的DHE_RSA公钥。
An OpenPGP certificate appearing in the certificate message is sent using the binary OpenPGP format. The certificate MUST contain all the elements required by Section 11.1 of [RFC4880].
证书消息中出现的OpenPGP证书使用二进制OpenPGP格式发送。证书必须包含[RFC4880]第11.1节要求的所有要素。
OpenPGP certificates to be transferred are placed in the Certificate structure and tagged with the OpenPGPCertDescriptorType "subkey_cert". Since those certificates might contain several subkeys, the subkey ID to be used for this session is explicitly
要传输的OpenPGP证书被放置在证书结构中，并用OpenPGPCertDescriptorType“subkey\u cert”标记。由于这些证书可能包含多个子密钥，因此此会话使用的子密钥ID是显式的
specified in the OpenPGPKeyID field. The key ID must be specified even if the certificate has only a primary key. The peer, upon receiving this type, has to either use the specified subkey or terminate the session with a fatal alert of "unsupported_certificate".
在OpenPGPKeyID字段中指定。即使证书只有主键，也必须指定密钥ID。对等方在收到此类型后，必须使用指定的子密钥或终止会话，并发出“unsupported_certificate”的致命警报。
The option is also available to send an OpenPGP fingerprint, instead of sending the entire certificate, by using the "subkey_cert_fingerprint" tag. This tag uses the OpenPGPSubKeyFingerprint structure and requires the primary key fingerprint to be specified, as well as the subkey ID to be used for this session. The peer shall respond with a "certificate_unobtainable" fatal alert if the certificate with the given fingerprint cannot be found. The "certificate_unobtainable" fatal alert is defined in Section 5 of [RFC6066].
该选项还可用于通过使用“subkey\u cert\u fingerprint”标记发送OpenPGP指纹，而不是发送整个证书。此标记使用OpenPGPSubKeyFingerprint结构，需要指定主键指纹以及用于此会话的子键ID。如果找不到具有给定指纹的证书，对等方应发出“证书不可获得”致命警报。[RFC6066]第5节定义了“无法获得证书”致命警报。
Implementations of this protocol MUST ensure that the sizes of key IDs and fingerprints in the OpenPGPSubKeyCert and OpenPGPSubKeyFingerprint structures comply with [RFC4880]. Moreover, it is RECOMMENDED that the keys to be used with this protocol have the authentication flag (0x20) set.
此协议的实现必须确保OpenPGPSubKeyCert和OpenPGPSUBKEYFIRMENT结构中的密钥ID和指纹的大小符合[RFC4880]。此外，建议在此协议中使用的密钥设置身份验证标志（0x20）。
The process of fingerprint generation is described in Section 12.2 of [RFC4880].
[RFC4880]第12.2节描述了指纹生成过程。
The enumerated types "cert_fingerprint" and "cert" of OpenPGPCertDescriptorType that were defined in [RFC5081] are not used and are marked as obsolete by this document. The "empty_cert" type has replaced "cert" and is a backward-compatible way to specify an empty certificate; "cert_fingerprint" MUST NOT be used with this updated specification, and hence that old alternative has been removed from the Certificate struct description.
[RFC5081]中定义的OpenPGPCertDescriptorType的枚举类型“cert_指纹”和“cert”未被使用，并被本文档标记为已过时。“empty_cert”类型已取代“cert”，是一种向后兼容的指定空证书的方式；“cert_fingerprint”不得与此更新的规范一起使用，因此已从证书结构描述中删除了旧的替代方案。
enum {
empty_cert(1),
subkey_cert(2),
subkey_cert_fingerprint(3),
(255)
} OpenPGPCertDescriptorType;
enum {
empty_cert(1),
subkey_cert(2),
subkey_cert_fingerprint(3),
(255)
} OpenPGPCertDescriptorType;
uint24 OpenPGPEmptyCert = 0;
uint24 OpenPGPEmptyCert=0；
struct {
opaque OpenPGPKeyID<8..255>;
opaque OpenPGPCert<0..2^24-1>;
} OpenPGPSubKeyCert;
struct {
opaque OpenPGPKeyID<8..255>;
opaque OpenPGPCert<0..2^24-1>;
} OpenPGPSubKeyCert;
struct {
opaque OpenPGPKeyID<8..255>;
opaque OpenPGPCertFingerprint<20..255>;
} OpenPGPSubKeyFingerprint;
struct {
opaque OpenPGPKeyID<8..255>;
opaque OpenPGPCertFingerprint<20..255>;
} OpenPGPSubKeyFingerprint;
struct {
OpenPGPCertDescriptorType descriptorType;
select (descriptorType) {
case empty_cert: OpenPGPEmptyCert;
case subkey_cert: OpenPGPSubKeyCert;
case subkey_cert_fingerprint:
OpenPGPSubKeyCertFingerprint;
}
} Certificate;
struct {
OpenPGPCertDescriptorType descriptorType;
select (descriptorType) {
case empty_cert: OpenPGPEmptyCert;
case subkey_cert: OpenPGPSubKeyCert;
case subkey_cert_fingerprint:
OpenPGPSubKeyCertFingerprint;
}
} Certificate;
The semantics of this message remain the same as in the TLS specification. However, if this message is sent, and the negotiated certificate type is OpenPGP, the "certificate_authorities" list MUST be empty.
此消息的语义与TLS规范中的相同。但是，如果发送此消息，并且协商的证书类型为OpenPGP，“证书颁发机构”列表必须为空。
This message is only sent in response to the certificate request message. The client certificate message is sent using the same formatting as the server certificate message, and it is also required to present a certificate that matches the negotiated certificate type. If OpenPGP certificates have been selected and no certificate is available from the client, then a certificate structure of type "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. The server SHOULD respond with a "handshake_failure" fatal alert if client authentication is required.
此消息仅在响应证书请求消息时发送。客户端证书消息使用与服务器证书消息相同的格式发送，并且还需要提供与协商的证书类型匹配的证书。如果已选择OpenPGP证书，但客户端没有可用的证书，则必须发送包含OpenPGPEmptyCert值的“empty_cert”类型的证书结构。如果需要客户端身份验证，服务器应发出“握手失败”致命警报。
All the other handshake messages are identical to the TLS specification.
所有其他握手消息都与TLS规范相同。
All security considerations discussed in [RFC5246], [RFC6066], and [RFC4880] apply to this document. Considerations about the use of the web of trust or identity and certificate verification procedures are outside the scope of this document. These are considered issues to be handled by the application layer protocols.
[RFC5246]、[RFC6066]和[RFC4880]中讨论的所有安全注意事项均适用于本文档。关于使用信任网或身份和证书验证程序的考虑不在本文件范围内。这些被认为是应用层协议要处理的问题。
The protocol for certificate type negotiation is identical in operation to cipher suite negotiation as described in the TLS specification [RFC5246], with the addition of default values when the extension is omitted. Since those omissions have a unique meaning and the same protection is applied to the values as with cipher suites, it is believed that the security properties of this negotiation are the same as with cipher suite negotiation.
证书类型协商协议在操作上与TLS规范[RFC5246]中描述的密码套件协商相同，只是在省略扩展时添加了默认值。由于这些遗漏具有独特的含义，并且对值的保护与对密码套件的保护相同，因此相信此协商的安全属性与对密码套件协商的安全属性相同。
When using OpenPGP fingerprints instead of the full certificates, the discussion in Section 5 of [RFC6066] for "Client Certificate URLs" applies, especially when external servers are used to retrieve keys. However, a major difference is that although the "client_certificate_url" extension allows identifying certificates without including the certificate hashes, this is not possible in the protocol proposed here. In this protocol, the certificates, when not sent, are always identified by their fingerprint, which serves as a cryptographic hash of the certificate (see Section 12.2 of [RFC4880]).
当使用OpenPGP指纹而不是完整证书时，[RFC6066]第5节中关于“客户端证书URL”的讨论适用，特别是当使用外部服务器检索密钥时。然而，一个主要的区别是，尽管“client_certificate_url”扩展允许在不包含证书哈希的情况下识别证书，但在本文提出的协议中这是不可能的。在该协议中，未发送的证书始终由其指纹标识，指纹用作证书的加密散列（见[RFC4880]第12.2节）。
The information that is available to participating parties and eavesdroppers (when confidentiality is not available through a previous handshake) is the number and the types of certificates they hold, plus the contents of the certificates.
参与方和窃听者可获得的信息（当通过先前的握手无法获得机密性时）是他们持有的证书的数量和类型，以及证书的内容。
This document uses a registry and the "cert_type" extension originally defined in [RFC5081]. Existing IANA references have been updated to point to this document.
本文档使用注册表和[RFC5081]中最初定义的“证书类型”扩展。现有IANA参考已更新，以指向本文件。
In addition, the "TLS Certificate Types" registry established by [RFC5081] has been updated in the following ways:
此外，[RFC5081]建立的“TLS证书类型”注册表已通过以下方式更新：
1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
1. 本文档中定义了值0（X.509）和1（OpenPGP）。
2. Values from 2 through 223 decimal inclusive are assigned via "RFC Required" [RFC5226].
2. 通过“需要RFC”[RFC5226]分配从2到223（含）十进制的值。
3. Values from 224 decimal through 255 decimal inclusive are reserved for Private Use [RFC5226].
3. 从224位十进制数到255位十进制数（含）的值保留供私人使用[RFC5226]。
The authors wish to thank Alfred Hoenes and Ted Hardie for their suggestions on improving this document.
作者希望感谢Alfred Hoenes和Ted Hardie就改进本文件提出的建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，2011年1月。
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 5081, November 2007.
[RFC5081]Mavrogiannopoulos，N.，“使用OpenPGP密钥进行传输层安全（TLS）认证”，RFC 5081，2007年11月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
This document incorporates a major change in the "Server Certificate" and "Client Certificate" TLS messages that will make implementations following this protocol incompatible with those following [RFC5081]. This change requires the subkey IDs used for TLS authentication to be marked explicitly in the handshake procedure. This was decided in order to place no limitation on the OpenPGP certificates' contents that can be used with this protocol.
本文档包含了“服务器证书”和“客户端证书”TLS消息中的重大更改，这将使遵循此协议的实现与遵循[RFC5081]的实现不兼容。此更改要求在握手过程中显式标记用于TLS身份验证的子密钥ID。这是为了不限制可用于此协议的OpenPGP证书的内容而决定的。
[RFC5081] required that an OpenPGP key or subkey be marked with the authentication flag; thus, authentication would have failed if this flag was not set or if this flag was set in more than one subkey. The protocol in this memo has no such limitation.
[RFC5081]要求使用认证标志标记OpenPGP密钥或子密钥；因此，如果未设置此标志或在多个子密钥中设置了此标志，则身份验证将失败。本备忘录中的协议没有此类限制。
Authors' Addresses
作者地址
Nikos Mavrogiannopoulos ESAT/COSIC Katholieke Universiteit Leuven Kasteelpark Arenberg 10, bus 2446 Leuven-Heverlee, B-3001 Belgium
Nikos Mavrogiannopoulos ESAT/COSIC Katholieke大学鲁汶卡斯蒂尔帕克阿伦伯格10号巴士2446路鲁汶Heverlee，B-3001比利时
EMail: nikos.mavrogiannopoulos@esat.kuleuven.be
EMail: nikos.mavrogiannopoulos@esat.kuleuven.be
Daniel Kahn Gillmor Independent 119 Herkimer St. Brooklyn, NY 11216-2801 US
Daniel Kahn Gillmor Independent美国纽约州布鲁克林赫尔基默街119号11216-2801
EMail: dkg@fifthhorseman.net
EMail: dkg@fifthhorseman.net