Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: STIR

RFC 8224

Authenticated Identity Management in the Session Initiation Protocol (SIP)

Pages: 46
Proposed STD
Errata
Obsoletes:  4474
Part 1 of 3 – Pages 1 to 14
None   None   Next

Top   ToC   RFC8224 - Page 1
Internet Engineering Task Force (IETF)                       J. Peterson
Request for Comments: 8224                                       NeuStar
Obsoletes: 4474                                              C. Jennings
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                              E. Rescorla
                                                              RTFM, Inc.
                                                                C. Wendt
                                                                 Comcast
                                                           February 2018


                   Authenticated Identity Management
                in the Session Initiation Protocol (SIP)

Abstract

   The baseline security mechanisms in the Session Initiation Protocol
   (SIP) are inadequate for cryptographically assuring the identity of
   the end users that originate SIP requests, especially in an
   interdomain context.  This document defines a mechanism for securely
   identifying originators of SIP requests.  It does so by defining a
   SIP header field for conveying a signature used for validating the
   identity and for conveying a reference to the credentials of the
   signer.

   This document obsoletes RFC 4474.

Status of This Memo

   This 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 has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8224.
Top   ToC   RFC8224 - Page 2
Copyright Notice

   Copyright (c) 2018 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
   (https://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.

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Architectural Overview ..........................................5
   4. Identity Header Field Syntax ....................................7
      4.1. PASSporT Construction ......................................8
           4.1.1. Example Full and Compact Forms of PASSporT
                  in Identity ........................................10
   5. Example of Operations ..........................................11
      5.1. Example Identity Header Construction ......................13
   6. Signature Generation and Validation ............................14
      6.1. Authentication Service Behavior ...........................14
           6.1.1. Handling Repairable Errors .........................16
      6.2. Verifier Behavior .........................................17
           6.2.1. Authorization of Requests ..........................19
           6.2.2. Failure Response Codes Sent by a
                  Verification Service ...............................19
           6.2.3. Handling Retried Requests ..........................21
           6.2.4. Handling the Full Form of PASSporT .................21
   7. Credentials ....................................................22
      7.1. Credential Use by the Authentication Service ..............22
      7.2. Credential Use by the Verification Service ................23
      7.3. "info" Parameter URIs .....................................24
      7.4. Credential System Requirements ............................25
   8. Identity Types .................................................26
      8.1. Differentiating Telephone Numbers from URIs ...............26
      8.2. Authority for Telephone Numbers ...........................27
      8.3. Telephone Number Canonicalization Procedures ..............28
      8.4. Authority for Domain Names ................................29
      8.5. URI Normalization .........................................30
   9. Extensibility ..................................................31
   10. Backwards Compatibility with RFC 4474 .........................32
Top   ToC   RFC8224 - Page 3
   11. Privacy Considerations ........................................32
   12. Security Considerations .......................................34
      12.1. Protected Request Fields .................................34
           12.1.1. Protection of the To Header and Retargeting .......36
      12.2. Unprotected Request Fields ...............................37
      12.3. Malicious Removal of Identity Headers ....................37
      12.4. Securing the Connection to the Authentication Service ....38
      12.5. Authorization and Transitional Strategies ................39
      12.6. Display-Names and Identity ...............................40
   13. IANA Considerations ...........................................40
      13.1. SIP Header Fields ........................................40
      13.2. SIP Response Codes .......................................41
      13.3. Identity-Info Parameters .................................41
      13.4. Identity-Info Algorithm Parameter Values .................41
   14. Changes from RFC 4474 .........................................41
   15. References ....................................................42
      15.1. Normative References .....................................42
      15.2. Informative References ...................................43
   Acknowledgments ...................................................46
   Authors' Addresses ................................................46

1.  Introduction

   This document provides enhancements to the existing mechanisms for
   authenticated identity management in the Session Initiation Protocol
   (SIP) [RFC3261].  An identity, for the purposes of this document, is
   defined as either

   o  a canonical address-of-record (AoR) SIP URI employed to reach a
      user (such as "sip:alice@atlanta.example.com") or

   o  a telephone number, which commonly appears either in a tel URI
      [RFC3966] or as the user portion of a SIP URI.

   [RFC3261] specifies several places within a SIP request where users
   can express an identity for themselves, most prominently the
   user-populated From header field.  However, in the absence of some
   sort of cryptographic authentication mechanism, the recipient of a
   SIP request has no way to verify that the From header field has been
   populated appropriately.  This leaves SIP vulnerable to a category of
   abuses such as impersonation attacks that facilitate or enable
   robocalling, voicemail hacking, swatting, and related problems as
   described in [RFC7340].  Ideally, a cryptographic approach to
   identity can provide a much stronger assurance of identity than the
   Caller ID services that the telephone network provides today, and one
   less vulnerable to spoofing.
Top   ToC   RFC8224 - Page 4
   [RFC3261] encourages user agents (UAs) to implement a number of
   potential authentication mechanisms, including Digest authentication,
   Transport Layer Security (TLS), and S/MIME (implementations may
   support other security schemes as well).  However, few SIP UAs today
   support the end-user certificates necessary to authenticate
   themselves (via S/MIME, for example), and for its part Digest
   authentication is limited by the fact that the originator and
   destination must share a prearranged secret.  Practically speaking,
   originating UAs need to be able to securely communicate their users'
   identities to destinations with which they have no previous
   association.

   As an initial attempt to address this gap, [RFC4474] specified a
   means of signing portions of SIP requests in order to provide an
   identity assurance.  However, [RFC4474] was in several ways
   misaligned with deployment realities (see [SIP-RFC4474-CONCERNS]).
   Most significantly, [RFC4474] did not deal well with telephone
   numbers as identifiers, despite their enduring use in SIP
   deployments.  [RFC4474] also provided a signature over material that
   intermediaries in existing deployments commonly altered.  This
   specification therefore deprecates the syntax and behavior specified
   by [RFC4474], reconsidering the problem space in light of the threat
   model in [RFC7375] and aligning the signature format with PASSporT
   (Personal Assertion Token) [RFC8225].  Backwards-compatibility
   considerations are given in Section 10.

2.  Terminology

   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 [RFC2119].

   In addition, this document uses three terms specific to the
   mechanism:

   o  Identity: An identifier for the user of a communications service;
      for the purposes of SIP, either a SIP URI or a telephone number.
      Identities are derived from an "identity field" in a SIP request
      such as the From header field.

   o  Authentication Service: A logical role played by a SIP entity that
      adds Identity headers to SIP requests.

   o  Verification Service (or "Verifier"): A logical role played by a
      SIP entity that validates Identity headers in a SIP request.
Top   ToC   RFC8224 - Page 5
3.  Architectural Overview

   The identity architecture for SIP defined in this specification
   depends on a logical "authentication service" that validates outgoing
   requests.  An authentication service may be implemented either as
   part of a UA or as a proxy server; typically, it is a component of a
   network intermediary like a proxy to which originating UAs send
   unsigned requests.  Once the originator of the message has been
   authenticated, through prearranged means with the authentication
   service, the authentication service then creates and adds an Identity
   header field to the request.  This requires computing cryptographic
   information -- including a digital signature over some components of
   messages -- that lets other SIP entities verify that the sending user
   has been authenticated and its claim of a particular identity has
   been authorized.  These "verification services" validate the
   signature and enable policy decisions to be made based on the results
   of the validation.

   Policy decisions made after validation depend heavily on the
   verification service's trust for the credentials that the
   authentication service uses to sign requests.  As robocalling,
   voicemail hacking, and swatting usually involve impersonation of
   telephone numbers, credentials that will be trusted by relying
   parties to sign for telephone numbers are a key component of the
   architecture.  Authority over telephone numbers is, however, not as
   easy to establish on the Internet as authority over traditional
   domain names.  This document assumes the existence of credentials for
   establishing authority over telephone numbers for cases where the
   telephone number is the identity of the user, but does not mandate or
   specify a credential system; [RFC8226] describes a credential system
   compatible with this architecture.

   Although addressing the vulnerabilities in the Secure Telephone
   Identity Revisited (STIR) problem statement [RFC7340] and threat
   model mostly requires dealing with telephone number as identities,
   SIP must also handle signing for SIP URIs as identities.  This is
   typically easier to deal with, as these identities are issued by
   organizations that have authority over Internet domains.  When a new
   user becomes associated with example.com, for example, the
   administrator of the SIP service for that domain can issue them an
   identity in that namespace, such as sip:alice@example.com.  Alice may
   then send REGISTER requests to example.com that make her UAs eligible
   to receive requests for sip:alice@example.com.  In other cases, Alice
   may herself be the owner of her own domain and may issue herself
   identities as she chooses.  But ultimately, it is the controller of
   the SIP service at example.com that must be responsible for
   authorizing the use of names in the example.com domain.  Therefore,
   for the purposes of SIP as defined in [RFC3261], the necessary
Top   ToC   RFC8224 - Page 6
   credentials needed to prove that a user is authorized to use a
   particular From header field must ultimately derive from the domain
   owner: either (1) a UA gives requests to the domain name owner in
   order for them to be signed by the domain owner's credentials or
   (2) the UA must possess credentials that prove that the domain owner
   has given the UA the right to a name.

   In order to share a cryptographic assurance of end-user SIP identity
   in an interdomain or intradomain context, an authentication service
   constructs tokens based on the PASSporT format [RFC8225], which is
   special encoding of a JSON [RFC8259] object comprising values derived
   from certain header field values in the SIP request.  The
   authentication service computes a signature over those JSON elements
   as PASSporT specifies.  An encoding of the resulting PASSporT is then
   placed in the SIP Identity header field.  In order to assist in the
   validation of the Identity header field, this specification also
   describes a parameter of the Identity header field that can be used
   by the recipient of a request to recover the credentials of the
   signer.

   Note that the scope of this document is limited to providing an
   identity assurance for SIP requests; solving this problem for SIP
   responses is outside the scope of this work (see [RFC4916]).  Future
   work might specify ways that a SIP implementation could gateway
   PASSporTs to other protocols.
Top   ToC   RFC8224 - Page 7
4.  Identity Header Field Syntax

   The Identity and Identity-Info header fields that were previously
   defined in [RFC4474] are deprecated by this document.  This revised
   specification collapses the grammar of Identity-Info into the
   Identity header field via the "info" parameter.  Note that unlike the
   prior specification in [RFC4474], the Identity header field is now
   allowed to appear more than one time in a SIP request.  The revised
   grammar for the Identity header field builds on the ABNF [RFC5234] in
   [RFC3261], Section 25.  It is as follows:

      Identity = "Identity" HCOLON signed-identity-digest SEMI
          ident-info *( SEMI ident-info-params )
      signed-identity-digest = 1*(base64-char / ".")
      ident-info = "info" EQUAL ident-info-uri
      ident-info-uri = LAQUOT absoluteURI RAQUOT
      ident-info-params = ident-info-alg / ident-type /
          ident-info-extension
      ident-info-alg = "alg" EQUAL token
      ident-type = "ppt" EQUAL token
      ident-info-extension = generic-param

      base64-char = ALPHA / DIGIT / "/" / "+"

   In addition to the "info" parameter, and the "alg" parameter
   previously defined in [RFC4474], this specification defines the
   optional "ppt" parameter (PASSporT Type).  The "absoluteURI" portion
   of ident-info-uri MUST contain a URI; see Section 7.3 for more on
   choosing how to advertise credentials through this parameter.

   The signed-identity-digest contains a base64 encoding of a PASSporT
   [RFC8225], which secures the request with a signature that PASSporT
   generates over the JSON header and payload objects; some of those
   header and claim element values will mirror values of the SIP
   request.
Top   ToC   RFC8224 - Page 8
4.1.  PASSporT Construction

   For SIP implementations to populate the PASSporT header JSON object
   with fields from a SIP request, the following elements MUST be placed
   as the values corresponding to the designated JSON keys:

   o  First, per the baseline PASSporT specification [RFC8225], the JSON
      "typ" key MUST have the value "passport".

   o  Second, the JSON key "alg" MUST mirror the value of the optional
      "alg" parameter in the SIP Identity header field.  Note that if
      the "alg" parameter is absent from the Identity header, the
      default value is "ES256".

   o  Third, the JSON key "x5u" MUST have a value equivalent to the
      quoted URI in the "info" parameter, per the simple string
      comparison rules of [RFC3986], Section 6.2.1.

   o  Fourth, if a PASSporT extension is in use, then the optional JSON
      key "ppt" MUST be present and have a value equivalent to the
      quoted value of the "ppt" parameter of the Identity header field.

   An example of the PASSporT header JSON object without any
   extension is:

   { "typ":"passport",
     "alg":"ES256",
     "x5u":"https://www.example.com/cert.cer" }

   To populate the PASSporT payload JSON object from a SIP request, the
   following elements MUST be placed as values corresponding to the
   designated JSON keys:

   o  First, the JSON "orig" object MUST be populated.  If the
      originating identity is a telephone number, then the array MUST be
      populated with a JSON object containing a "tn" element with a
      value set to the value of the quoted originating identity, a
      canonicalized telephone number (see Section 8.3).  Otherwise, the
      object MUST be populated with a JSON object containing a "uri"
      element, set to the value of the AoR of the UA sending the message
      as taken from the addr-spec of the From header field, per the
      procedures in Section 8.5.

   o  Second, the JSON "dest" array MUST be populated.  If the
      destination identity is a telephone number, then the array MUST be
      populated with a JSON object containing a "tn" element with a
      value set to the value of the quoted destination identity, a
      canonicalized telephone number (see Section 8.3).  Otherwise, the
Top   ToC   RFC8224 - Page 9
      array MUST be populated with a JSON object containing a "uri"
      element, set to the value of the addr-spec component of the
      To header field, which is the AoR to which the request is being
      sent, per the procedures in Section 8.5.  Multiple JSON objects
      are permitted in "dest" for future compatibility reasons.

   o  Third, the JSON key "iat" MUST appear.  The authentication service
      SHOULD set the value of "iat" to an encoding of the value of the
      SIP Date header field as a JSON NumericDate (as UNIX time, per
      [RFC7519], Section 2), though an authentication service MAY set
      the value of "iat" to its own current clock time.  If the
      authentication service uses its own clock time, then the use of
      the full form of PASSporT is REQUIRED.  In either case, the
      authentication service MUST NOT generate a PASSporT for a SIP
      request if the Date header is outside of its local policy for
      freshness (sixty seconds is RECOMMENDED).

   o  Fourth, if the request contains a Session Description Protocol
      (SDP) message body and if that SDP contains one or more
      "a=fingerprint" attributes, then the JSON key "mky" MUST appear
      with the algorithm(s) and value(s) of the fingerprint attributes
      (if they differ), following the format given in [RFC8225],
      Section 5.2.2.

   For example:

   { "orig":{"tn":"12155551212"},
     "dest":{"tn":["12155551213"]},
     "iat":1443208345 }

   For information on the security properties of these SIP message
   elements and why their inclusion mitigates replay attacks, see
   Section 12.  Note that future extensions to PASSporT could introduce
   new claims and that further SIP procedures could be required to
   extract information from the SIP request to populate the values of
   those claims; see Section 9 of this document.

   The "orig" and "dest" arrays may contain identifiers of heterogeneous
   type; for example, the "orig" array might contain a "tn" claim, while
   the "dest" contains a "uri" claim.  Also note that in some cases, the
   "dest" array may be populated with more than one value.  This could,
   for example, occur when multiple "dest" identities are specified in a
   meshed conference.  Defining how a SIP implementation would align
   multiple destination identities in PASSporT with such systems is left
   as a subject for future specifications.
Top   ToC   RFC8224 - Page 10
   After these two JSON objects, the header and the payload, have been
   constructed and base64-encoded, they must each be hashed and signed
   per [RFC8225], Section 6.  The header, payload, and signature
   components comprise a full PASSporT object.  The resulting PASSporT
   may be carried in SIP in either (1) a full form, which includes the
   header and payload as well as the signature or (2) a compact form,
   which only carries the signature per [RFC8225], Section 7.  The
   hashing and signing algorithm is specified by the "alg" parameter of
   the Identity header field and the mirrored "alg" parameter of
   PASSporT.  All implementations of this specification MUST support the
   required signing algorithms of PASSporT.  At present, there is one
   mandatory-to-support value for the "alg" parameter: "ES256", as
   defined in [RFC7519], which connotes an Elliptic Curve Digital
   Signature Algorithm (ECDSA) P-256 digital signature.

4.1.1.  Example Full and Compact Forms of PASSporT in Identity

   As Appendix F of the JSON Web Signature (JWS) specification [RFC7515]
   notes, there are cases where "it is useful to integrity-protect
   content that is not itself contained in a JWS."  Since the fields
   that make up the majority of the PASSporT header and payload have
   values replicated in the SIP request, the SIP usage of PASSporT may
   exclude the base64-encoded version of the header and payload JSON
   objects from the Identity header field and instead present a detached
   signature: what PASSporT calls its compact form; see [RFC8225],
   Section 7.

   When an authentication service constructs an Identity header, the
   contents of the signed-identity-digest field MUST contain either a
   full or compact PASSporT.  Use of the compact form is RECOMMENDED in
   order to reduce message size, but note that extensions often require
   the full form (see Section 9).

   For example, a full form of PASSporT in an Identity header might look
   as follows (backslashes shown for line folding only):

   Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
   joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \
   kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
   I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
   q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
   ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \
   /biloxi.cert>
Top   ToC   RFC8224 - Page 11
   The compact form of the same PASSporT object would appear in the
   Identity header as:

   Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \
   pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w;                    \
   info=<https://biloxi.example.org/biloxi.cert>

5.  Example of Operations

   This section provides an informative (non-normative) high-level
   example of the operation of the mechanisms described in this
   document.

   Imagine a case where Bob, who has the home proxy of example.com and
   the AoR sip:12155551212@example.com;user=phone, wants to communicate
   with Alice at sip:alice@example.com.  They have no prior
   relationship, and Alice implements best practices to prevent
   impersonation attacks.

   Bob's UA generates an INVITE and places his AoR in the From header
   field of the request.  He then sends an INVITE to an authentication
   service proxy for his domain.

   ............................          ..............................
   .                          .          .                            .
   .                +-------+ .          . +-------+                  .
   .     Signs for  |       | .  Signed  . |       |                  .
   .     12125551xxx| Auth  |------------> | Verif |                  .
   .                |  Svc  | .  INVITE  . |  Svc  |                  .
   .                | Proxy | .          . | Proxy |                  .
   .              > +-------+ .          . +-------+ \                .
   .             /       |    .          ->           \               .
   .            /        |    .        --.             \              .
   .           /         |    .      --  .              \             .
   .          /          |    .    --    .               \            .
   .         /       +-------+.  --      .                \           .
   .        /        |       |.<-        .                 \          .
   .       /         | Cert  |.          .                  >         .
   .   +-------+     | Store |.          .                +-------+   .
   .   |       |     |       |.          .                |       |   .
   .   | Bob   |     +-------+.          .                | Alice |   .
   .   | UA    |              .          .                | UA    |   .
   .   |       |              .          .                |       |   .
   .   +-------+              .          .                +-------+   .
   .              Domain A    .          .   Domain B                 .
   ............................          ..............................
Top   ToC   RFC8224 - Page 12
   The proxy authenticates Bob and validates that he is authorized to
   assert the identity that he populated in the From header field.  The
   proxy authentication service then constructs a PASSporT that contains
   a JSON representation of values that mirror certain parts of the SIP
   request, including the identity in the From header field value.  As a
   part of generating the PASSporT, the authentication service signs a
   hash of that JSON header and payload with the private key associated
   with the appropriate credential for the identity (in this example, a
   certificate with authority to sign for numbers in a range from
   12155551000 to 12155551999), and the signature is inserted by the
   proxy server into the Identity header field value of the request as a
   compact form of PASSporT.  Alternatively, the JSON header and payload
   themselves might also have been included in the object when using the
   full form of PASSporT.

   The proxy authentication service, as the holder of a private key with
   authority over Bob's telephone number, is asserting that the
   originator of this request has been authenticated and that he is
   authorized to claim the identity that appears in the From header
   field.  The proxy inserts an "info" parameter into the Identity
   header field that tells Alice how to acquire keying material
   necessary to validate its credentials (a public key), in case she
   doesn't already have it.

   When Alice's domain receives the request, a proxy verification
   service validates the signature provided in the Identity header field
   and then determines that the authentication service credentials
   demonstrate authority over the identity in the From header field.
   This same validation operation might be performed by a verification
   service in Alice's UA server (UAS).  Ultimately, this valid request
   is rendered to Alice.  If the validation were unsuccessful, some
   other treatment could be applied by the receiving domain or
   Alice's UA.
Top   ToC   RFC8224 - Page 13
5.1.  Example Identity Header Construction

   For the following SIP request:

    INVITE sip:alice@example.com SIP/2.0
    Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
    To: Alice <sip:alice@example.com>
    From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774>
    Call-ID: a84b4c76e66710
    CSeq: 314159 INVITE
    Max-Forwards: 70
    Date: Fri, 25 Sep 2015 19:12:25 GMT
    Contact: <sip:12155551212@gateway.example.com>
    Content-Type: application/sdp
    Content-Length: ...

    v=0
    o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
    s=Session SDP
    c=IN IP4 pc33.atlanta.example.com
    t=0 0
    m=audio 49172 RTP/AVP 0
    a=rtpmap:0 PCMU/8000

   An authentication service will create a corresponding PASSporT
   object.  The properly serialized PASSporT header and payload JSON
   objects would look as follows.  For the header, the values chosen by
   the authentication service at "example.com" might read:

   {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/
      passport.cer"}

   The serialized payload will derive values from the SIP request (the
   From, To, and Date header field values) as follows:

   {"dest":{"uri":["sip:alice@example.com"]},"iat":1443208345,
     "orig":{"tn":"12155551212"}}

   The authentication service would then generate the signature over the
   object, following the procedures in [RFC8225], Section 6.  That
   signature would look as follows:

   rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
    ojNCpTzO3QfPOlckGaS6hEck7w
Top   ToC   RFC8224 - Page 14
   An authentication service signing this request and using the compact
   form of PASSporT would thus generate and add to the request an
   Identity header field of the following form:

   Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
    lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
    info=<https://cert.example.org/passport.cer>



(page 14 continued on part 2)

Next Section