RFC 5408
Identity-Based Encryption Architecture and Supporting Data Structures
RFC 5408 🎀 Identity-Based Encryption Architecture and Supporting Data Structures
okay bestie, let's start with the vibes check ✨ this is RFC 5408, titled Identity-Based Encryption Architecture and Supporting Data Structures 💅 it was written by G. Appenzeller (Stanford University), L. Martin (Voltage Security), and M. Schertler (Axway) 🧚 it's dated January 2009 and its category is Informational 🌸 so it's not a standard, just info for the Internet community 🫶 it doesn't obsolete or update anything else 💜
Network Working Group, same squad as always 😭
Status of This Memo 📜
okay so this bit is the legal-ish intro 🙈 it says this memo provides information for the Internet community and it does not specify an Internet standard of any kind 💅 distribution is unlimited, so share it with your whole group chat 🦋
Copyright Notice ©️
copyright is Copyright (c) 2009 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 (http://trustee.ietf.org/license-info) as they were on the publication date, so read those carefully bc they're your rights and restrictions 🎀
Abstract 🔮
this doc describes the security architecture you need to implement identity-based encryption, which is a public-key encryption tech that uses a user's identity as a public key 🦋 it also defines data structures you can use to build it 🌈
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Identity-Based Encryption .......................................3
2.1. Overview ...................................................3
2.2. Sending a Message That Is IBE-Encrypted ....................5
2.2.1. Sender Obtains Public Parameters ....................5
2.2.2. Construct and Send an IBE-Encrypted Message .........6
2.3. Receiving and Viewing an IBE-Encrypted Message .............6
2.3.1. Recipient Obtains Public Parameters .................7
2.3.2. Recipient Obtains IBE Private Key ...................8
2.3.3. Recipient Decrypts IBE-Encrypted Message ............8
3. Identity Format .................................................9
4. Public Parameter Lookup .........................................9
4.1. Request Method ............................................10
4.2. Parameter and Policy Format ...............................11
4.3. The application/ibe-pp-data MIME Type .....................14
5. Private Key Request Protocol ...................................15
5.1. Overview ..................................................15
5.2. Private Key Request .......................................15
5.3. Request Structure .........................................16
5.4. The application/ibe-key-request+xml MIME type .............17
5.5. Authentication ............................................18
5.6. Server Response Format ....................................18
5.6.1. The IBE100 responseCode ............................19
5.6.2. The IBE101 responseCode ............................20
5.6.3. The IBE201 responseCode ............................20
5.6.4. The IBE300 responseCode ............................21
5.6.5. The IBE301 responseCode ............................21
5.6.6. The IBE303 responseCode ............................21
5.6.7. The IBE304 responseCode ............................22
5.7. The application/ibe-pkg-reply+xml MIME type ...............22
6. ASN.1 Module ...................................................23
7. Security Considerations ........................................25
7.1. Attacks outside the Scope of This Document ................25
7.2. Attacks within the Scope of This Document .................26
7.2.1. Attacks on the Protocols Defined in This Document ..26
8. IANA Considerations ............................................27
8.1. Media Types ...............................................27
8.2. XML Namespace .............................................27
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................291. Introduction 🌷
this doc describes the security architecture you need to implement identity-based encryption, the public-key tech where a user's identity acts as their public key 🫶 it also defines the data structures you need to build it 💖 objects are defined using ASN.1 [ASN1] and XML [XML] 🧚
1.1. Terminology 📚
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 [KEY] 🔥
2. Identity-Based Encryption 🔐
2.1. Overview 🌈
okay so identity-based encryption (IBE) is a public-key encryption thing where a public key can be calculated from an identity plus a set of public mathematical parameters 🦋 and the matching private key can be calculated from that identity, those same public parameters, and a domain-wide secret value 💅 anyone with the public parameters can work out an IBE public key, but you need a cryptographic secret to work out the private key, and only a trusted server holding that secret can do it 👑
the wild part: both keys can be calculated whenever you need them, so they're made just-in-time ✨ this is different from other public-key systems [P1363], where keys are randomly generated and handed out before secure chat starts, and private keys have to be securely archived so they can be recovered if lost or destroyed 😭 being able to calculate a recipient's public key means the sender and receiver don't have to talk first, either directly or through a proxy like a directory server, before sending secure messages 🙈 iconic, honestly 💜
another cool thing: once you fetch a set of public parameters, you can encrypt with no more server contact during their validity period 🎀 other server-based systems may need a connection to a server for every single encryption operation 💀
this doc describes an IBE-based messaging system, how its parts work together, and the data structures that keep it running 🌸 the server components it needs are:
- A Public Parameter Server (PPS). IBE public parameters include publicly-sharable cryptographic material, known as IBE public parameters, and policy information for an associated PKG. a PPS gives you a well-known spot to securely grab IBE public parameters and policy info that describe how a PKG works 🧚 Section 5 of this document describes the protocol a client uses to talk to a PPS 💖
- A Private-key Generator (PKG). the PKG stores and uses cryptographic material called a master secret, which it uses to generate a user's IBE private key 🔑 a PKG accepts an IBE user's private key request and, after authenticating them somehow, returns their IBE private key 🌟 Section 5 of this document describes the protocol a client uses to talk to a PKG 🫶
a logical setup would be one PKG and one PPS per name space, like a DNS zone 🍓 the organization that controls the DNS zone also controls the PKG and PPS, so it decides which PKG or PPS gets used when creating keys for its members 👑 in that case the PPS URI/IRI can be built from a user-friendly name for the form of identity the PPS supports 💅 this makes it obvious which public parameters to use and where to get them for a given identity (like an RFC 2821 address [SMTP]) 🦋
IBE-encrypted messages can use standard message formats, like the Cryptographic Message Syntax [CMS] ✨ how to use IBE with CMS to encrypt email is defined in [IBECMS] 📧
heads up: IBE algorithms are only used for encryption, so if you need digital signatures, you'll need a separate mechanism for that 🚨
Section 3 of this document describes the identity format that all PPS and PKG servers MUST support.
2.2. Sending a Message That Is IBE-Encrypted 💌
to send an encrypted message, an IBE user has to do the following steps 🎀
- Obtain the recipient's public parameters
the recipient's system public parameters are needed for IBE operations 💖 once a user has them, they can do IBE encryption 🧚 these parameters might live on a PPS run by the user's org, one run by the sender's org, or a totally different org 🌸
- Construct and send an IBE-encrypted message
besides the IBE public parameters, all you need to build an IBE-encrypted message is the recipient's identity, and its form is set by the public parameters ✨ when that identity matches the address a message would normally go to, you need no more info to send someone an encrypted message than you'd need for an unencrypted one 🦋 this is one of the biggest perks of an IBE-based secure messaging system 👑 identities can be individual, group, or role identifiers 🫶
2.2.1. Sender Obtains Public Parameters 📮
the sender grabs the IBE public parameters they need from a PPS hosted at a well-known URI or IRI 💅 the public parameters have everything the sender needs to make an IBE-encrypted message except the recipient's identity 🎀 Section 4 of this document describes the URI [URI] or IRI [IRI] of a PPS, the format of IBE public parameters, and how to get them from a PPS 🌈 the URI or IRI users get IBE public parameters from MUST be authenticated somehow 🔐 PPS servers MUST support TLS 1.2 [TLS] to meet this requirement and SHOULD support its successors 🔥 this step is shown in Figure 1 below 🧚
IBE Public Parameter Request
----------------------------->
Sender PPS
<-----------------------------
IBE Public Parameters
Figure 1: Requesting IBE Public Parametersthe sender of an IBE-encrypted message picks the PPS and matching PKG based on their local security policy 🌸 different PPS servers might give public parameters that specify different IBE algorithms or different key strengths, for example 💜 or they might require PKG servers that need different levels of authentication before handing out IBE private keys 🙈
2.2.2. Construct and Send an IBE-Encrypted Message ✨
okay so to IBE-encrypt a message, the sender picks a content-encryption key (CEK) 🔑 and uses it to encrypt the message itself. Then they encrypt that CEK with the recipient's IBE public key, as described in [CMS]. Figure 2 shows the whole vibe 💅. [IBCS] has the algorithms you need for two forms of IBE, and [IBECMS] explains how to use the Cryptographic Message Syntax (CMS) to wrap up the encrypted message with the IBE info the recipient needs to decrypt an email 🎀.
CEK ----> Sender ----> IBE-encrypted CEK
^
|
|
Recipient's Identity
and IBE Public Parameters
Figure 2: Using an IBE Public-key Algorithm to Encrypt2.3. Receiving and Viewing an IBE-Encrypted Message 📬
so to actually read an IBE-encrypted message, the recipient parses it to find the URI or IRI they need. That URI or IRI is how they get the IBE public parameters required for IBE calculations, plus a component of the identity that was used to encrypt the message 🧚. Then they run through these steps:
- Obtain the IBE public parameters 🗝️
An IBE system's public parameters let it uniquely create public and private keys. The recipient can decrypt an IBE-encrypted message if they have both the IBE public parameters and the necessary IBE private key. The public parameters also give the URI or IRI of the PKG where the recipient can get the IBE private keys.
- Obtain the IBE private key from the PKG 🔐
To decrypt an IBE-encrypted message, the recipient needs the IBE public parameters and also the private key that matches the public key the sender used. The IBE private key is obtained after successfully authenticating to a private key generator (PKG), which is a trusted third party that calculates private keys for users. The recipient then receives the IBE private key over a secure connection.
- Decrypt the IBE-encrypted Message 🔓
The IBE private key decrypts the CEK (see Section 2.3.3). The CEK is then used to decrypt the encrypted message.
It may be useful for a PKG to let users other than the intended recipient receive some IBE private keys 👀. Giving a mail-filtering appliance permission to obtain IBE private keys on behalf of users, for example, can let the appliance decrypt and scan encrypted messages for viruses or other malicious features 🦋.
2.3.1. Recipient Obtains Public Parameters 🌸
before the recipient can do any IBE calculations for the message, they need to grab the IBE public parameters that were used in the encryption. Figure 3 shows this. Using the correct public parameters is vital to the overall security of an IBE system, so IBE public parameters MUST be transported to recipients over a secure protocol 🔒. PPS servers MUST support TLS 1.2 [TLS] or its successors, using the latest version supported by both parties, for transport of IBE public parameters. Users MUST also verify that the subject name in the server certificate matches the URI/IRI of the PPS. The comments in Section 2.2.1 also apply to this operation.
IBE Public Parameter Request
----------------------------->
Recipient PPS
<-----------------------------
IBE Public Parameters
Figure 3: Requesting IBE Public Parameters2.3.2. Recipient Obtains IBE Private Key 🧁
to get an IBE private key, the recipient gives the PKG the IBE public key that was used to encrypt the message, along with their authentication credentials. Then they request the private key that matches that IBE public key. Section 5 of this document defines the protocol for communicating with a PKG, plus a minimum interoperable way to authenticate to a PKG that all IBE implementations MUST support 🤝. Because the security of IBE private keys is vital to the overall security of an IBE system, IBE private keys MUST be transported to recipients over a secure protocol. PKG servers MUST support TLS 1.2 [TLS] or its successors, using the latest version supported by both parties, for transport of IBE private keys. Figure 4 shows this one.
IBE Private Key Request
---------------------------->
Recipient PKG
<----------------------------
IBE Private Key
Figure 4: Obtaining an IBE Private Key2.3.3. Recipient Decrypts IBE-Encrypted Message 💖
once they've got the necessary IBE private key, the recipient uses it along with the matching IBE public parameters to decrypt the CEK. Figure 5 shows this. Then they use the CEK to decrypt the encrypted message content. An example of how to do this with email messages is given in [IBECMS] ✨.
IBE-encrypted CEK ----> Recipient ----> CEK
^
|
|
IBE Private Key
and IBE Public Parameters
Figure 5: Using an IBE Public-Key Algorithm to Decrypt3. Identity Format 🪪
An IBEIdentityInfo type MUST be used to represent the identity of a recipient. It's defined like this:
IBEIdentityInfo ::= SEQUENCE {
district IA5String,
serial INTEGER,
identityType OBJECT IDENTIFIER,
identityData OCTET STRING
}An IBEIdentityInfo type is used to calculate public and private IBE keys. Because of this, the structure is typically DER-encoded [DER] 🍓.
The fields of an IBEIdentityInfo structure have the following meanings:
The district is an IA5String that represents the URI [URI] or IRI [IRI] where the recipient of an IBE-encrypted message can retrieve the IBE public parameters needed to encrypt or decrypt a message encrypted for this identity. Applications MUST support the method described in Section 4 for doing this and MAY support other methods. IRIs MUST be handled according to the procedures specified in Section 7.4 of [PKIX] 🌈.
The serial is an INTEGER that defines a unique set of IBE public parameters in the event that more than one set of parameters is used by a single district 🔢.
identityType is an OBJECT IDENTIFIER that defines the format that the identityData field is encoded with 🧩.
An example of a useful IBEIdentityInfo type is given in [IBECMS]. This example is tailored to the use of IBE in encrypting email 📧. Because the information that makes up an identity is very dependent on the application, this document does not define an identityType that all applications MUST support 🙈.
4. Public Parameter Lookup 🔍
This section specifies how a component of an IBE system can retrieve the public parameters. A sending or receiving client MUST allow these parameters to be configured manually, for example through editing a configuration file. However, for simplified configuration, a client SHOULD also implement the public parameter URI/IRI request method described in this document, so it can fetch the public parameters based on a configured URI/IRI. This is especially useful for federating between IBE systems 🌐. By specifying a single URI/IRI, a client can be configured to fetch all the relevant parameters for a remote PKG. These public parameters can then be used to encrypt messages to recipients who authenticate to and retrieve private keys from that PKG.
The following section outlines the URI/IRI request method to retrieve a parameter block and describes the structure of the parameter block itself. The technique for fetching IBE public parameters using the process defined in this section is indicated by the OID uriPPSOID, which is defined like this:
uriPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
}4.1. Request Method 🎯
The configuration URI/IRI SHOULD be an HTTPS URI [HTTP] and MAY additionally support IRIs [IRI] for this purpose. To retrieve the IBE public parameters, the client SHOULD use the HTTP GET method as defined in [HTTP]. The request MUST happen over a secure protocol. The requesting client MUST support TLS 1.2 [TLS] or its successors and SHOULD use the latest version supported by both parties. When requesting the URI/IRI, the client MUST only accept the system parameter block if the server identity was verified successfully by TLS 1.2 [TLS] or its successors.
bestie, the cert and TLS checks are not optional vibes, they're the whole point 🙈🔒
A successful GET request returns in its body the base64 [B64] encoding of the DER-encoded [DER] IBESysParams structure that is described in the next section. This structure MUST be encoded as an application/ibe-pp-data MIME type 💜.
4.2. Parameter and Policy Format 💅
okay so the public parameters are a structure that looks like this 🎀
IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) },
districtName IA5String,
districtSerial INTEGER,
validity ValidityPeriod,
ibePublicParameters IBEPublicParameters,
ibeIdentityType OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL
}Here's what each field in an IBESysParams structure is up to 🧚
The version field tells you which version of the IBESysParams format you're looking at. For the format in this document, it MUST be set to 2 🔥
The districtName field is an IA5String that MUST be an encoding of a URI [URI] or IRI [IRI]. IRIs MUST be handled according to the procedures in Section 7.4 of [PKIX] 🌸
The districtSerial field is an integer that stands for a unique set of IBE public parameters available at the URI or IRI defined by the districtName. If new parameters get published for a districtName, the districtSerial MUST be increased to a number bigger than the previously-used districtSerial. no going backwards bestie 📈
The validity field defines the lifetime of one specific instance of the IBESysParams, and it's defined like this:
ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}The values of notBefore and notAfter MUST be written in Greenwich Mean Time (Zulu). They MUST include seconds (times are always YYYYMMDDHHMMSSZ), even when the seconds are zero, and MUST be expressed to the nearest second. ⏰
A client MUST verify that the date it uses the IBE public parameters on falls between the notBefore time and the notAfter time of those parameters. If it doesn't, it MUST NOT use the parameters for IBE encryption operations. not okay, not allowed 🙅♀️
IBE public parameters MUST be regenerated and republished whenever the values of ibePublicParameters, ibeIdentityType, or ibeParamExtensions change for a district. A client SHOULD refetch the IBE public parameters at an application-configurable interval, so it always has the most current version 🔄
It's possible to make identities for IBE that have a time component, as described in [IBECMS], for example. If you use one of those, the time component of the identity MUST fall between the notBefore time and the notAfter time of the IBE public parameters. timing is everything ⏳
IBEPublicParameters is a structure holding public parameters for the IBE algorithms that the PKG supports. It's defined to be the following:
IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}The ibeAlgorithm OID specifies an IBE algorithm. The OIDs for two IBE algorithms (Boneh-Franklin and Boneh-Boyen) and their publicParameterData structures are defined in [IBCS] 🧠
The publicParameterData is a DER-encoded [DER] structure containing the actual cryptographic parameters. Its exact structure depends on the algorithm 🔐
The IBESysParams of a district MUST contain an OID that identifies at least one algorithm, and MAY contain OIDs that identify more than one. It MUST NOT contain two or more IBEPublicParameter entries with the same algorithm. A client that wants to use IBESysParams can choose any of the algorithms specified in the publicParameterData structure. A client MUST implement at least the Boneh-Franklin algorithm [IBCS] and MAY implement the Boneh-Boyen [IBCS] and other algorithms. If a client doesn't support any of the supported algorithms, it MUST generate an error message and fail. 💀
ibeIdentityType is an OID that defines the type of identities used with this district. The OIDs, and the required and optional fields for each OID, are application dependent. An example is given in [IBECMS], which defines an identity format suitable for encrypting email 📧
IBEParamExtensions is a set of extensions that can define additional parameters particular implementations might need. It's defined as follows:
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING
}The contents of the octet string ibeParamExtensionValue are defined by the specific ibeParamExtensionOID. The IBEParamExtensions of a district MAY have any number of extensions, including zero. One example that's been used in practice is providing a URI where an encrypted message can be decrypted and viewed by users of webmail systems. Another is commercial branding info, so a bank can show a different user interface to customers of different lines of business 🏦✨
If a client receives public parameters containing an extension it can't process, it MUST NOT use the values in the IBESysParams structure for any cryptographic operations. Clients MUST be able to process an IBESysParams structure that has no IBEParamExtensions. ✅
The pkgURI OID defined below marks an IBEParamExtensions structure that contains the URI or IRI of a Private Key Generator. When this OID shows up in an IBEParamExtension, clients MUST use the protocol defined in Section 5 of this document to get IBE private keys from the PKG, and MUST do so using the URI/IRI given by the ibeParamExtensionValue in that IBEParamExtension. 🗝️
If the PKG is publicly accessible, this extension SHOULD be present, so private keys can be retrieved automatically for recipients of encrypted messages. For this extension, the ibeParamExtensionValue OCTET STRING is an IA5String holding the URI [URI] or IRI [IRI] of the PKG where IBE private keys can be obtained. IRIs MUST be handled according to the procedures specified in Section 7.4 of [PKIX] 💖
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }4.3. The application/ibe-pp-data MIME Type 🎀
Here's the rundown on the application/ibe-pp-data MIME type 💅
- MIME media type name:
application - MIME subtype name:
ibe-pp-data - Mandatory parameters: none
- Optional parameters: none
- Encoding considerations: This media type MUST be encoded as 7-bit (US-ASCII text [ASCII]).
- Security considerations: The data conveyed as this media type are the public parameters needed for the operation of a cryptographic system. To ensure that the parameters can be trusted, the request for these parameters must take place over a secure protocol, such as TLS 1.2 or its successors. To ensure the validity of the server, the client MUST verify the server certificate and MUST abort the parameter request if the verification of the server certificate of the TLS connection fails. This media type contains no active content and does not use compression. 😭🔒
- Interoperability considerations: There are no known interoperability considerations for this media type.
- Applications that use this media type: Applications that implement IBE in compliance with this specification will use this media type. The most commonly used of these applications are encrypted email and file encryption. 📬
- Additional information: none
- Person and email address for further information: Luther Martin,
martin@voltage.com. - Intended usage:
COMMON - Author/Change controller: Luther Martin,
martin@voltage.com.
5. Private Key Request Protocol 🗝️
5.1. Overview
When requesting a private key, a client has to send three parameters, bestie 📝
- The IBE algorithm the key is being requested for
- The identity the client is requesting a key for
- Authentication credentials for the individual requesting the key
The identity a client requests a key for doesn't necessarily match the identity the authentication credentials validate. This can happen when one user has access to multiple aliases. For example, an email user might have access to the keys for two different email addresses, e.g., bob@example.com and bob.smith@example.com. two Bobs, one person 👀
This section defines the protocol for requesting private keys, a minimum user authentication method for interoperability, and how to pass authentication credentials to the server. It assumes a client has already figured out the URI/IRI of the PKG. That can be done from information included in the IBE message format and the public parameters of the IBE system. 🧩
The technique for fetching an IBE private key using the process defined in this section is indicated by the OBJECT IDENTIFIER pkgURI, which is defined to be the following:
ibcs OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1)
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }5.2. Private Key Request
To request a private key, a client MUST perform an HTTP POST method as defined in [HTTP]. The request MUST take place over a secure protocol. The requesting client MUST support TLS 1.2 [TLS] or its successors, using the latest version supported by both the client and the PKG. When requesting the URI/IRI, the client MUST verify the server certificate [HTTPTLS], and it MUST abort the key request if the server certificate verification of the TLS connection fails. this part is SO important, because it's how you keep the credentials and the private key safe from man-in-the-middle attacks as they travel from the key server to the client 🛡️🫶
5.3. Request Structure ✨
Okay so the POST method carries an XML structure in its body, and that body MUST be encoded as an application/ibe-key-request+xml MIME type 💖:
<ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:header>
<ibe:client version="clientID"/>
</ibe:header>
<ibe:body>
<ibe:keyRequest>
<ibe:algorithm>
algorithmOID
</ibe:algorithm>
<ibe:id>
ibeIdentityInfo
</ibe:id>
</ibe:keyRequest>
<ibe:authData>
ibeAuthData
</ibe:authData>
</ibe:body>
</ibe:request>A <ibe:request> SHOULD include an <ibe:client> element in the <ibe:header> part of a key request. That element holds an ASCII string naming the client type and client version 🎀.
A key request MUST contain an <ibe:oid> element. It holds the base64 [B64] encoding of a DER-encoded [DER] object identifier, which identifies the algorithm you're asking a key for 🔥. OIDs for the Boneh-Boyen (BB1) and Boneh-Franklin (BF) algorithms are listed in [IBCS].
A key request MUST contain an <ibe:id> element with the identity the private key is being requested for 🦋. That identity is the base64 [B64] encoding of a DER-encoded [DER] ASN.1 structure. The structure defines a user's identity in whatever way fits the application. An example that works for encrypting email is defined in [IBECMS] 💅.
A key request MAY contain an <ibe:authData> element. This is where authentication info goes, and the PKG can use it to decide whether a request for a particular IBE private key gets granted 🔐.
A client MAY add optional extra XML elements in the <ibe:body> part of the key request. A PKG MUST be able to process key requests that have none of those optional elements, so no excuses 😭.
5.4. The application/ibe-key-request+xml MIME type 🌸
Here's the rundown on the application/ibe-key-request+xml MIME type:
- MIME media type name: application
- MIME subtype name: ibe-key-request+xml
- Mandatory parameters: none
- Optional parameters: none
- Encoding considerations: This media type MUST be encoded as US-ASCII [ASCII].
- Security considerations: Okay this one is serious, bestie 😭. The data in this media type may carry authentication credentials, so its confidentiality and integrity are extremely important. To keep that safe, the request for an IBE private key must go over a secure protocol, like TLS 1.2 or its successors. To make sure the server is legit, the client MUST verify the server certificate and MUST abort the key request if verifying the server certificate of the TLS connection fails. The good news is this media type has no active content and doesn't use compression 🧚.
- Interoperability considerations: There are no known interoperability considerations for this media type ✨.
- Applications that use this media type: Any application that implements IBE in compliance with this specification will use this media type. The most commonly used ones are encrypted email and file encryption 💌.
- Additional information: none
- Person and email address for further information: Luther Martin, martin@voltage.com.
- Intended usage: COMMON
- Author/Change controller: Luther Martin, martin@voltage.com.
5.5. Authentication 🔑
When a client asks a PKG for a key, the PKG MUST authenticate the client before issuing that key. Authentication may be done through the key request structure, or as part of the secure transport protocol. Pick your fighter 💜.
A client or server implementing the request protocol MUST support HTTP Basic Auth [AUTH], and SHOULD also support HTTP Digest Auth [AUTH]. Applications MAY also use other means of authentication that suit the application. An email application, for example, might lean on the email infrastructure it already has 📧.
For authentication methods that aren't handled by the transport protocol, a client MAY include extra authentication info in XML elements inside the <ibe:authData> element of a key request. If a client doesn't know how to authenticate to a server, the client MAY send a key request with no authentication info at all. If the key server needs the client to authenticate externally, it MAY reply with an IBE201 responseCode (as defined below) to redirect the client to the right authentication mechanism. Once the client gets an authentication credential from that external mechanism, it can use the credential to build a key request that carries the extra authentication data 🦋.
5.6. Server Response Format 🎀
The key server replies to the HTTP request with an HTTP response. If that response has a client error or server error status code, the client MUST abort the key request and fail 💀.
If the PKG replies with an HTTP response whose status code means success, the body of the reply MUST contain the following XML structure, which MUST be encoded as an application/ibe-pkg-reply+xml MIME type:
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="responseCode"/>
<ibe:body>
bodyTags
</ibe:body>
</ibe:response>The responseCode attribute holds an ASCII string that describes what kind of response the key server is giving you. These are the currently-defined responseCodes and what they mean 👑:
IBE100 KEY_FOLLOWS
IBE101 RESERVED
IBE201 FOLLOW_ENROLL_URI
IBE300 SYSTEM_ERROR
IBE301 INVALID_REQUEST
IBE303 CLIENT_OBSOLETE
IBE304 AUTHORIZATION DENIED5.6.1. The IBE100 responseCode 🍓
If the key request succeeded, the key server responds with a responseCode of IBE100, and the <ibe:body> MUST contain an <ibe:privateKey> element holding a valid private key. Here's what that looks like:
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE100"/>
<ibe:body>
<ibe:privateKey>
privateKey
</ibe:privateKey>
</ibe:body>
</ibe:response>The privateKey is the base64 [B64] encoding of the DER encoding [DER] of the following structure 🔥:
IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo,
pgkAlgorithm OBJECT IDENTIFIER,
pkgKeyData OCTET STRING,
pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption
}
PKGOption ::= SEQUENCE {
optionID OBJECT IDENTIFIER,
optionValue OCTET STRING
}The pkgIdentity is an IBEIdentityInfo structure that MUST be identical to the IBEIdentityInfo structure that was sent in the key request 🔁.
The pkgAlgorithm is an OID that identifies the algorithm of the returned private key. The OIDs for the BB1 and BF algorithms are defined in [IBCS].
The pkgKeyData is a structure that holds the actual private key. Private-key formats for the BB1 and BF algorithms are defined in [IBCS].
A server MAY pass additional information back to a client in the pkgOptions structure. Now here's the important bit 🚨: a client that receives an IBEPrivateKeyReply from a PKG containing pkgOptions information it is unable to process MUST NOT use the IBE private key in that IBEPrivateKeyReply structure for any cryptographic operations. A client MUST be able to process an IBEPrivateKeyReply that contains no PKGOptions structure.
5.6.2. The IBE101 responseCode 🙈
The responseCode IBE101 is reserved to keep things interoperable with earlier versions of the protocol described in this document. Here's an example of such a response. A response with the IBE101 responseCode SHOULD contain no body. If there is information in the body of such a response, the client receiving it MUST discard any data contained in the body 🗑️.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE101"/>
<ibe:body>
This message must be discarded by the recipient
</ibe:body
</ibe:response>5.6.3. The IBE201 responseCode 🗺️
A PKG MAY support authenticating users to external authentication mechanisms. If it does, the server replies to the client with responseCode IBE201, and the body of the response MUST contain a <ibe:location> element that specifies the URI of the authentication mechanism. Example time:
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE201"/>
<ibe:body>
<ibe:location
URI="http://www.example.com/enroll.asp"/>
</ibe:body>
</ibe:response>The client can now contact the URI from that response, using the same mechanisms defined in Section 5.2, to get an authentication credential. Once the client has that credential from the authentication mechanism at this URI, it sends a new key request to the PKG with the correct credentials included. It puts the credential in the <ibe:authData> element of the key request, as described in Section 5.5 🫶.
5.6.4. The IBE300 responseCode 💥
The IBE300 responseCode means an internal server error has happened. Information that might help diagnose the error MAY be included in the body of such a response. Here's an example:
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE300"/>
<ibe:body>
Widget phlebotomy failure
</ibe:body>
</ibe:response>Upon receiving a IBE300 responseCode, the client MUST abort the key request and discard any data that was included in the body of the response 🛑.
5.6.5. The IBE301 responseCode 🧐
The IBE303 responseCode indicates that an invalid key request has been received by the server. Information that may help diagnose the error MAY be included in the body of such a response. Here's an example:
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE301"/>
<ibe:body>
Some additional stuff
</ibe:body>
</ibe:response>Upon receiving an IBE301 responseCode, the client MUST abort the key request and discard any data that was included in the body of the response 🙃.
5.6.6. The IBE303 responseCode 📱
The IBE303 responseCode indicates that the server can't correctly process the request, because the version of the request is no longer supported by the server. Information that may help diagnose the error MAY be included in the body of such a response.
Here's an example of such a response. Upon receiving an IBE303 responseCode, the client MUST abort the key request and discard any data that was included in the body of the response 🌈.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE303"/>
<ibe:body>
Version 3.3 or later needed
</ibe:body>
</ibe:response>5.6.7. The IBE304 responseCode ✨
okay so the IBE304 responseCode means the server got a valid key request, but the authentication credentials were wrong 🙈 the server MAY include some helpful error info in the body to help figure out what went wrong. here's what that looks like:
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE304"/>
<ibe:body>
Helpful error message
</ibe:body>
</ibe:response>and the big rule: once the client gets an IBE304, it MUST abort the key request and throw away anything that came in the body of that response 💅 no peeking!!
5.7. The application/ibe-pkg-reply+xml MIME type 🎀
here's the lowdown on the application/ibe-pkg-reply+xml MIME type 💜
- MIME media type name: application
- MIME subtype name: ibe-pkg-reply+xml
- Mandatory parameters: none
- Optional parameters: none
- Encoding considerations: this media type MUST be encoded as US-ASCII [ASCII].
- Security considerations: okay this one is SERIOUS 😭 the data in this media type is an IBE private key, so keeping it confidential and making sure nobody messes with it is extremely important. the response from the server that carries the IBE private key has to happen over a secure protocol, like TLS 1.2 or whatever comes after it. to make sure you're talking to the real server, the client MUST verify the server certificate, and MUST abort the key request if verifying the server certificate of the TLS connection fails. also this media type has no active content and doesn't use compression 🔥
- Interoperability considerations: there are no known interoperability considerations for this media type 🌸
- Applications that use this media type: apps that implement IBE following this spec will use this media type. the most common ones are encrypted email and file encryption ✨
- Additional information: none
- Person and email address for further information: Luther Martin, martin@voltage.com.
- Intended usage: COMMON
- Author/Change controller: Luther Martin, martin@voltage.com.
6. ASN.1 Module 🧚
this is the ASN.1 module that sums up all the ASN.1 definitions we talked about in this document, so here it is in one place 💖
IBEARCH-module { joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) ibearch(5)
module(5) version(1)
}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) },
districtName IA5String,
districtSerial INTEGER,
validity ValidityPeriod,
ibePublicParameters IBEPublicParameters,
ibeIdentityType OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL
}
ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING
}
ibcs OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1)
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo,
pgkAlgorithm OBJECT IDENTIFIER,
pkgKeyData OCTET STRING,
pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption
}
PKGOption ::= SEQUENCE {
optionID OBJECT IDENTIFIER,
optionValue OCTET STRING
}
uriPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
}
IBEIdentityInfo ::= SEQUENCE {
district IA5String,
serial INTEGER,
identityType OBJECT IDENTIFIER,
identityData OCTET STRING
}
END7. Security Considerations 🔐
7.1. Attacks outside the Scope of This Document 🙅♀️
attacks on the crypto algorithms that power IBE are outside the scope of this doc. those are covered in [IBCS], which defines parameters that give 80-bit, 112-bit, and 128-bit encryption strength. we assume that capable admins of an IBE system will pick parameters that hold up well against cryptanalytic attacks from adversaries 💪
attacks that let an adversary access or change the info on a PPS or PKG, especially the crypto material (called the master secret in this document), will absolutely wreck the security of an IBE system 😭 if that crypto material gets compromised, the adversary can recreate ANY user's private key and then decrypt every message protected with the matching public key. to deal with this, it is highly RECOMMENDED that best practices for physical and operational security for PPS and PKG servers be followed, and that these servers be configured (sometimes called hardened) in line with current best practices [NIST]. an IBE system SHOULD be run in an environment where it's infeasible for attackers to get illicit access 🛡️
attacks that need administrative access, or access equivalent to an IBE user, on machines used by the client or server components defined in this document are also outside the scope of this doc.
we also assume all admins of a system implementing the protocols in this document are trustworthy and won't abuse their power to get around the security an IBE system provides. similarly, we assume IBE users will behave responsibly and won't share their authentication credentials with others. so attacks that depend on those assumptions are outside the scope of this doc 🫶
7.2. Attacks within the Scope of This Document 👀
the attacks that ARE in scope are the ones that let an adversary:
- passively monitor information sent between IBE users and the PPS and PKG
- masquerade as a PPS or PKG
- perform a denial-of-service (DoS) attack on a PPS or PKG
- easily guess an IBE user's authentication credential
7.2.1. Attacks on the Protocols Defined in This Document 🚨
all communications between IBE users and the PPS or PKG are protected using TLS 1.2 [TLS]. the IBE system in this document adds no extra security protections for those communications. so the described IBE system is completely dependent on TLS for authenticating the PKG or PPS server and for keeping communications confidential and intact. if the TLS security mechanisms ever get compromised, the integrity of all communications between an IBE user and the PPS or PKG will be suspect 😬
the protocols in this document don't explicitly defend against an attacker pretending to be a legit IBE PPS or PKG. they rely on the server authentication mechanism of TLS [TLS]. on top of TLS server authentication, IBE client software can help protect against this by offering UI features that let users visually check that their connection to the PPS and PKG servers is legit. this extra step can help make sure users can't easily be tricked into handing their valid authorization credentials to an attacker 👑
the protocols here are also vulnerable to attacks against an IBE PPS or PKG. denial-of-service attacks against either component can leave users unable to encrypt or decrypt using IBE, and users of an IBE system SHOULD take the appropriate countermeasures [DOS, BGPDOS] that their use of IBE requires ⚡
the IBE user authentication method picked by an IBE PKG SHOULD be strong enough to stop attackers from easily guessing the IBE user's authentication credentials through trial and error 🔑
8. IANA Considerations 📋
8.1. Media Types 🎀
with this specification, IANA has registered three media types in the standard registration tree: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml. application/ibe-pp-data is defined in Section 4.3 of this document. application/ibe-key-request+xml is defined in Section 5.4 of this document. application/ibe-pkg-reply+xml is defined in Section 5.7 of this document ✨
8.2. XML Namespace 🌈
IANA is requested to register the following namespace identifier:
urn:ietf:params:xml:ns:ibeRegistrant Contact:
Luther Martin
Voltage Security
1070 Arastradero Rd Suite 100
Palo Alto, CA 94304
Phone: +1 650 543 1280
Email: martin@voltage.comXML:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Identity-Based Encryption</title>
</head>
<body>
<h1>Namespace for Identity-Based Encryption</h1>
<h2>urn:ietf:params:xml:ns:ibe</h2>
<p>
<a href="http://www.rfc-editor.org/rfc/rfc5408.txt">RFC5408</a>.
</p>
</body>
</html>9. References 📚
9.1. Normative References 📚💖
okay bestie, these are the must-read docs the spec leans on, so no skipping 🫶
[ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7-bit Coded
Character Set for Information Exchange.
[ASN1] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One, 1997.
[AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[B64] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[DER] ITU-T Recommendation X.690: OSI Networking and System
Aspects: Abstract Syntax Notation One (ASN.1), July 2002.
[DOS] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[HTTP] 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.
[HTTPTLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[IBCS] Boyen, X. and L. Martin, "Identity-Based Cryptography
Standard (IBCS) #1: Supersingular Curve Implementations of
the BF and BB1 Cryptosystems", RFC 5091, December 2007.
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[KEY] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PKIX] 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.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth Edition),
September 2006.9.2. Informative References 🦋
these ones are the extra reading for when you want the full story 🎀
[BGPDOS] Turk, D., "Configuring BGP to Block Denial-of-Service
Attacks", RFC 3882, September 2004.
[IBECMS] Martin, L. and M. Schertler, "Using the Boneh-Franklin
Identity-Based Encryption Algorithm with the Cryptographic
Message Syntax (CMS)", RFC 5409, January 2009.
[NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration
Checklist Program for IT Products - Guidance for Checklist
Users and Developers", NIST Special Publication SP 800-70,
May 2005.
[P1363] IEEE P1363, "Standard Specifications for Public-Key
Cryptography", 2001.Authors' Addresses 🌸
the people who wrote it, with their contact info 💅
Guido Appenzeller
Stanford University
Gates Building 3A
Stanford, CA 94305
Phone: +1 650 732 2273
EMail: appenz@cs.stanford.edu
Luther Martin
Voltage Security
1070 Arastradero Rd, Suite 100
Palo Alto, CA 94304
USA
Phone: +1 650 543 1280
EMail: martin@voltage.com
Mark Schertler
Axway
1600 Seaport Blvd, Suite 400
Redwood City, CA 94063
USA
Phone: +1 650 216 2039
EMail: mschertler@us.axway.comand that's the whole RFC, bestie 🧚✨ we did it!!
📦 where this page comes from
- ietf: rfc5408 2009-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms