Showing content from https://www.rfc-editor.org/rfc/rfc9734.xml below:
Introduction Instant Messaging (IM) systems using the Messaging Layer Security (MLS) protocol can incorporate per-client identity certificate credentials. A subjectAltName in these certificates can be an IM URI or Extensible Messaging and Presence Protocol (XMPP) URI , for example. Organizations may be unwilling to issue certificates for an IM client using a general KeyPurposeId, such as id-kp-serverAuth or id-kp-clientAuth, because of the risk that such certificates could be abused in a cross-protocol attack. An explanation of MLS credentials as they apply to IM is described in . These credentials are expected to be heavily used in the More Instant Messaging Interoperability (MIMI) Working Group. Conventions and Definitions The key words " MUST ", " MUST NOT ", " REQUIRED ", " SHALL ", " SHALL NOT ", " SHOULD ", " SHOULD NOT ", " RECOMMENDED ", " NOT RECOMMENDED ", " MAY ", and " OPTIONAL " in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The IM URI EKU This specification defines the KeyPurposeId id-kp-imUri, which may be included in certificates used to prove the identity of an IM client. This EKU extension MAY , at the option of the certificate issuer, be either critical or non-critical. id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } id-kp-imUri OBJECT IDENTIFIER ::= { id-kp 40 } Security Considerations The security considerations of are applicable to this document. The id-kp-imUri extended key purpose does not introduce new security risks but instead reduces existing security risks by providing means to identify if the certificate is generated to sign IM identity credentials. Issuers SHOULD NOT set the id-kp-imUri extended key purpose and an id-kp-clientAuth or id-kp-serverAuth extended key purpose: that would defeat the improved specificity offered by having an id-kp-imUri extended key purpose. IANA Considerations IANA has registered the following OID in the "SMI Security for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3). This OID is defined in . Decimal Description References 40 id-kp-imUri RFC 9734 IANA has also registered the following ASN.1 module OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). This OID is defined in . Decimal Description References 113 id-mod-im-eku RFC 9734 References Normative References Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation ITU-T Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ITU-T Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Identity for E2E-Secure Communications Cisco Rohan Mahy Consulting Service End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. Work in Progress Common Profile for Instant Messaging (CPIM) At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS-TRACK] Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK] The Messaging Layer Security (MLS) Protocol Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. ASN.1 Module The following module adheres to ASN.1 specifications and . <CODE BEGINS> IM-EKU { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-im-eku (113) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- OID Arc id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } -- Extended Key Usage Values id-kp-imUri OBJECT IDENTIFIER ::= { id-kp 40 } END <CODE ENDS> Acknowledgments Thanks to and for reviews, suggestions, corrections, and encouragement. Author's Address Rohan Mahy Consulting Services rohan.ietf@gmail.com
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4