Internet DRAFT - draft-abiggs-saag-primitives-for-conf-group-comms
draft-abiggs-saag-primitives-for-conf-group-comms
Network Working Group A. Biggs
Internet-Draft S. Cooley
Intended status: Standards Track Cisco Systems
Expires: May 6, 2016 November 03, 2015
Primitives for Confidential Group Communications
draft-abiggs-saag-primitives-for-conf-group-comms-01
Abstract
This specification defines generalized primitives for use in
establishing end-to-end confidentiality in multiparty communications.
These primitives address three essential elements of group privacy:
authentication, group membership, and secure key exchange. The
purpose is to define these primitives in such a way as they may be
leveraged as common constructs within new and existing secure group
communications protocols, and in support of both centralized and
decentralized architectures.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2016.
Copyright Notice
Copyright (c) 2015 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) 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
Biggs & Cooley Expires May 6, 2016 [Page 1]
Internet-Draft primitives-for-conf-group-comms November 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Authentication by Entity Public Key . . . . . . . . . . . 5
2.2. Authorization by Group Membership Block Chain . . . . . . 5
2.3. Key Distribution by Group Keys . . . . . . . . . . . . . 7
3. Group Models . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Decentralized Groups . . . . . . . . . . . . . . . . . . 8
3.2. Centralized Groups . . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Decentralized Group File Sharing . . . . . . . . . . . . 10
4.2. Centralized Group Instant Messaging . . . . . . . . . . . 11
5. Primitive Specifications . . . . . . . . . . . . . . . . . . 12
5.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Group Membership Block Chain . . . . . . . . . . . . . . 12
5.3. Group Key . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Mandatory-to-Implement . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . 14
9. Appendix B. Document History . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
This specification defines generalized primitives for use in
establishing end-to-end confidentiality in multiparty communications.
These primitives address three essential elements of group privacy:
o Authentication
o Group Membership
o Secure Key Exchange
Authentication is based on the identification of interoperating
entities by acct URI [RFC7565] and proof of possession of the private
counterpart of a public key discoverable through a public key
discovery service [I-D.miller-saag-key-discovery].
Biggs & Cooley Expires May 6, 2016 [Page 2]
Internet-Draft primitives-for-conf-group-comms November 2015
Authorization is based on the group membership classification of
authenticated entities, as represented in the form of a Group
Membership Block Chain (GMBC) structure defined by this
specification. Critical properties of the GMBC are tamper-
resistance, efficient mutability, broad deployability, and integrity
in the context of distributed handling.
The secure exchange of keys is based on existing key wrapping
standards which allow for the sharing of encrypted key material with
multiple explicitly identified recipients. This strategy builds on
the GMBC based authorization model by taking advantage of reliable
group membership classification when addressing wrapped keys to other
members.
A goal of this specification is to define these primitives in such a
way as they may be suitable for both centralized and distributed
management. It is also a goal to describe these primitives in terms
of accepted standards for cryptographic processing and
infrastructure.
A non-goal of this specification is to define the means by which
these primitives are exchanged among interoperating entities. The
intent is only to define these as building blocks for extending group
confidentiality to both new and existing communications and content
sharing protocols. With that in mind, however, this specification
does advance the notion of recognizing two general classes of
deployment for these primitives: "centralized" and "decentralized".
An additional non-goal of this specification is the establishment of
mechanisms for the authentication of sender identity in confidential
group communications. Care is taken to ensure that only
authenticated members of a group may decipher secured communications,
however the means by which group members may reliably identify
originators of encrypted communications is out of scope for this
specification.
1.1. Terminology
curator
An entity optionally identified in the genesis block of a GMBC as
a permanent member of a group that performs the function of
accepting and distributing GMBC updates and GKs among group
members.
entity
Biggs & Cooley Expires May 6, 2016 [Page 3]
Internet-Draft primitives-for-conf-group-comms November 2015
An entity is a user or automated agent that is uniquely
identifiable by an acct URI and for which there exists a key
discovery service [I-D.miller-saag-key-discovery] through which
public keys may be obtained for that URI.
genesis block
The first block in a group membership block chain.
group
A group is a set of entities whose membership wish to engage in
secure and authenticated multiparty communications over some group
communications resource.
member
A member is an entity that is classified as such with respect to a
particular group membership block chain. A non-member is any entity
not classified as a member.
group communications resource
A group communications resource is any uniquely identifiable
streamed or discrete data path that represents an exchange of
personal communications between two or more entities.
group key (GK)
A group key is a signed and encrypted object containing symmetric
key material and associated metadata secured by the public key(s)
of group members.
group membership block chain (GMBC)
A group membership block chain is a primitive defined by this
specification for the purpose of providing an effective means for
defining, updating, sharing, and verifying the membership of a
group.
This document uses the terminology from [RFC7515], [RFC7516],
[RFC7517], and [RFC7518] when discussing JOSE technologies. Most
security-related terms in this document are to be understood in the
sense defined in [RFC4949].
Biggs & Cooley Expires May 6, 2016 [Page 4]
Internet-Draft primitives-for-conf-group-comms November 2015
1.2. Notational Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. Overview
This section provides a general overview of three basic constructs
for enabling authentication, authorization, and secure key exchange
in confidential group communications.
2.1. Authentication by Entity Public Key
In the context of this specification entity authentication is defined
as the demonstration of possession of the private component of an
asymmetric key pair. Specifically, an entity uniquely identified by
an acct URI [RFC7565] may be authenticated by demonstrating
possession of the private counterpart of one or more public keys as
may be discovered using that acct URI and the mechanisms described in
[I-D.miller-saag-key-discovery].
2.2. Authorization by Group Membership Block Chain
In the context of this specification authorization is defined as the
classification of any given entity as either a "member" or "non-
member" with respect to a group. A member of the group is by
definition authorized to receive keying material used to encrypt
group communications, and likewise a non-member is not. A member is
also entitled to alter the membership of the group. The means by
which group membership classification established, updated, and
validated, is through operations on a Group Membership Block Chain
(GMBC).
A GMBC is an ordered list of data blocks representing a tamper-
resistant chronological account of group membership updates. The
first block in the GMBC defines the initial set of group members and
each subsequent block represents an addition/removal of one or more
other entities to/from the group. Any entity can create a GMBC, but
only a member can update an existing GMBC by appending new blocks to
it.
Each block consists of a JSON object signed with the private key of
the entity that created that block within the chain. That JSON
object includes attributes representing the following:
o the acct URI of the entity that created the block,
Biggs & Cooley Expires May 6, 2016 [Page 5]
Internet-Draft primitives-for-conf-group-comms November 2015
o an array of group membership update operations,
o a timestamp indicating the date and time of the block's creation,
and
o a hash of the preceding block in the membership chain (if any).
A group membership update operation is a JSON object with two fields:
o a tag indicating the operation type ("add" or "remove"), and
o the acct URI of the entity being either added to or removed from
the group.
In addition to the above attributes the first block of the chain, or
genesis block, also includes the following attributes:
o a URI that uniquely identifies the GMBC,
o the acct URI of the group's curator (optional), and
o a nonce.
The genesis block must also include at least one "add" operation,
though it need not necessarily represent the addition of the entity
that created it (i.e. entities may create new groups within which
they are not themselves members).
The membership of the group is implicit and may be determined by
processing the GMBC in chronological order. At any given point in
time the membership of the group is defined as that set of entities
for which there exists, for each entity, a previously introduced
block containing an "add" operation, and for which there does not
exist a later but also previously introduced block containing a
"remove" operation.
To protect against unauthorized tampering the GMBC is validated by
verifying the signatures of each block, verifying that each non-
genesis block contains a valid hash of the preceding block, and
verifying that each block was created and signed by an entity that is
among the group's membership as determined by the segment of chain
preceding that block. Block signature verification is made possible
through the key discovery mechanisms defined in
[I-D.miller-saag-key-discovery] and the knowledge of each member's
acct URI.
Biggs & Cooley Expires May 6, 2016 [Page 6]
Internet-Draft primitives-for-conf-group-comms November 2015
2.3. Key Distribution by Group Keys
A Group Key (GK) is signed object containing encrypted symmetric key
material with associated metadata. A GK exists for the purpose of
sharing the contained symmetric key with other members of the group.
The exclusivity of access to the key material is achieved by
encrypting the key material in such a way that it may be decrypted
with the private entity key(s) of any one of the other group members.
The creator signs the GK such that the authenticity of the associated
metadata may be verified by its recipients.
The payload of the GK is a JSON object includes attributes
representing the following:
o a URI that uniquely identifies the GK,
o the acct URI of the creator of the GK,
o a hash of the GMBC tail block at the time this key was created,
o an encrypted JWK [RFC7517] that contains the symmetric key
material, and
o a timestamp indicating the date and time the GK was created.
The JWK attribute value is encrypted in a JWE [RFC7516] JSON
serialization with one or more recipients. In decentralized groups
the resulting JWE JSON serialization must include each other member
of the group as determined by the current and validated GMBC. In
centralized groups the resulting JWE JSON serialization may include
as a recipient just the curator (e.g. when an entity shares a new GK)
or just one member (e.g. when the curator shares a GK with a member
that has requested it). The full JSON payload of the GK is signed as
a JWS [RFC7515] using the creator's private entity key.
GKs may be created by members and non-members alike. A non-member
may generate a GK as described above and use it to encrypt its own
communications to the group. This can be a useful property as it
provides for a confidential "write only" capability to the group
communications resource.
A group may have any number of GKs associated with it. Where
practical, it is recommended that each member of a group use its own
GK for purposes of encryption and share this GK with the remainder of
the group for purposes of decryption. A member must not re-use the
keying material of a GK created by another entity to encrypt it's own
communications unless it has verified that GK is signed by a current
member of the group as defined by the GMBC.
Biggs & Cooley Expires May 6, 2016 [Page 7]
Internet-Draft primitives-for-conf-group-comms November 2015
Upon receiving and validating an update to the GMBC, each entity must
discard their encryption GK and produce a new encryption GK for which
the recipients reflect the updated GMBC membership. This is
necessary to ensure that new members are able to decrypt subsequent
communications but not prior communications. Perhaps more
importantly, this also ensures that former members are not able to
decrypt subsequent group communications. In centralized groups the
curator may implement a policy where it permits new group members to
request previously created GKs.
It is recommended that all entities that share encrypted content over
the group communications resource rotate their GKs regularly so as to
mitigate against vulnerabilities that are exacerbated by the extended
use of individual keys.
3. Group Models
While this specification provides definition for constructs that
enable confidential group communications, the means by which these
objects may be exchanged among group members is intentionally omitted
as this is regarded as out of scope for this specification. It
remains worthwhile, however, to discuss two general classes of
confidential group communications and how the primitives defined by
this specification may be leveraged in each. These classes may be
described as "centralized groups" and "decentralized groups".
3.1. Decentralized Groups
A decentralized group is characterized by the absence of a curator
attribute in the GMBC genesis block and therefore the absence of a
permanent member within the group through which GMBC and GK objects
may be exchanged. In a decentralized group these objects may instead
be exchanged either in-band through the group communications resource
itself, or through in-band references to external repositories from
whence GMBC and GK objects may be retrieved.
Both the GMBC and GK objects are designed to be hardened against
tampering and protect sensitive data such that they may be reasonably
exchanged through either public or private transports and stores.
Note, however, that regardless of the employed mechanisms of exchange
a protocol utilizing a decentralized group pattern must provide a
means by which any GMBC update or new GK produced by a member may be
delivered to each other group member in a timely fashion.
In a decentralized group the fact that there is no single entity
providing an authoritative and definitively current version of the
GMBC means that members can make concurrent updates to their own
copies of the GMBC and thereby create conflicts in their collective
Biggs & Cooley Expires May 6, 2016 [Page 8]
Internet-Draft primitives-for-conf-group-comms November 2015
understanding of group membership history. Such conflicts are
manifest as a divergence where each GMBC has a different block, let
us call them B and B', appended to some block A that they have in
common. A member encountering this condition must select either one
of the two GMBCs in its entirety and discard the other. This
selection is performed by observing the hash values of blocks B and
B' and selecting the GMBC to which the block with the numerically
smallest hash belongs. If, as a result of this selection, an entity
finds that a block that it had itself previously introduced to the
discarded GMBC is not represented in the retained GMBC, then that
entity is responsible for appending a new block to the retained GMBC
to represent that membership update (and, of course, share that
update to other members).
3.2. Centralized Groups
A centralized group is characterized by the presence of a curator
attribute in the GMBC genesis block. The curator attribute
identifies an entity by its acct URI and declares that entity as a
permanent member of the group which will serve as a facilitator for
the exchange of GMBC and GK objects among all group members. In
particular, a curator will respond to the following types of requests
from other entities. Note that the means by which these operations
are carried out between members and the curator is out of scope for
this document.
GMBC Post
When adding or removing members from a group, a member will submit
a new GMBC block to the curator representing that change. The
curator will verify that the block is signed by a member of the
group and that the hash attribute of the block represents the hash
of the current tail end of the chain. If both checks succeed then
the curator will make the new block a permanent part of the GMBC
and indicate to the requesting entity that the update was
successful.
GMBC Get
Entities may request all or part of the current GMBC from the
curator by providing to the curator a hash of the last GMBC block
of which they are aware (or 0x0 if they are requesting the entire
chain).
GMBC Notify (optional)
In some deployments it may be desirable for a curator to
immediately multicast GMBC updates to all current members of the
Biggs & Cooley Expires May 6, 2016 [Page 9]
Internet-Draft primitives-for-conf-group-comms November 2015
group. This may be based on either an explicit or automatic/
implicit subscription model.
GK Post
Entities may inform the curator of new GKs which they have
generated for the purpose of encrypting data they emit to the
group communications resource. The curator will store a received
GKs such that it may subsequently service requests for that GK
from other members that wish to decrypt these communications.
GK Get
Members may request from the curator GKs which have been generated
by other entities. In doing so, an entity must indicate the URI
of the requested GK and the curator must verify that the
requesting entity was a member of the group at the time the GK was
created by processing the GMBC from the genesis block up to and
including the block whose hash is indicated in the metadata of the
requested GK. A successful confirmation of the requesting entity
as a member of the group at that point in time will result in the
curator generating a new GK which is in every way identical to the
requested GK except that the key material is re-encrypted using
the public key of the requesting entity and the GK itself is
signed using the curator's own public entity key.
4. Use Cases
The following are non-normative examples of how the primitives
described in this specification may be employed to facilitate
confidential group communications.
4.1. Decentralized Group File Sharing
This use case describes an application that utilizes some third party
file sharing service to store confidential information and employs
this specification as part of a scheme to secure that confidentiality
among the members of self defined group.
1. User A generates a symmetric key to be used for file encryption.
2. User A encrypts a file using the symmetric key and posts it to
the file sharing service.
3. User A generates a new GMBC by creating a genesis block. In that
block user A includes a reference to the URL of the encrypted
file on the file sharing service. User A also adds to the
Biggs & Cooley Expires May 6, 2016 [Page 10]
Internet-Draft primitives-for-conf-group-comms November 2015
genesis block three group membership "add" operations: one for
itself, one for user B, and one for user C.
4. User A creates a GK that includes a hash of the GMBC genesis
block, and encrypts the key material portion of the GK using a
multi-recipient JWE JSON serialization that indicates users B and
C as recipients.
5. User A posts the GMBC and GK as text files to the same file
sharing service, and sends the URLs of the encrypted content
file, the GMBC, and GK to users B and C.
6. User B recognizes user A's acct URI as the identity of a trusted
correspondent, retrieves the GMBC and GK from the file service,
and verifies the signatures on the GMBC genesis block and GK by
discovering and retrieving user A's public entity key through
[I-D.miller-saag-key-discovery].
7. User B uses its own private entity key to decrypt the key
material contained within the GK, downloads the file indicated by
the resource URL in the GMBC genesis block, and decrypts the
contents of that file.
8. User C repeats the procedure outlined for user B in steps 6 and
7.
4.2. Centralized Group Instant Messaging
This use case describes an application that utilizes some instant
messaging service to exchange confidential messages among a group of
users and employs this specification as part of a scheme to secure
that confidentiality among the members as a centralized group.
1. User A establishes a messaging thread on the messaging service
that includes users B and C. We presume it can be associated
with some unique URI for purposes of identification.
2. User A generates a new GMBC by creating a genesis block. In that
block user A includes a reference to the URI of the messaging
thread created in step 2, and three group membership "add"
operations: one for itself, one for user B, and one for user C.
User A also identifies itself as the curator of the group by
provisioning the genesis block with its own acct URI in the
curator field.
3. User A creates a GK that includes a hash of the GMBC genesis
block.
Biggs & Cooley Expires May 6, 2016 [Page 11]
Internet-Draft primitives-for-conf-group-comms November 2015
4. User A encrypts a message using the keying material of the GK and
sends it over the instant messaging service. As metadata within
that message it also includes the URI of the GK it used to
encrypt the message and the current GMBC.
5. User B recognizes user A's acct URI as the identity of a trusted
correspondent and validates the GMBC as originating from user A
by discovering and retrieving user A's public entity key through
[I-D.miller-saag-key-discovery].
6. User B observes that the GMBC indicates user A as the curator for
this group and sends a request (perhaps as an in-band extension
to the instant messaging protocol) to user A for the GK used to
encrypt the message sent in step 3.
7. User A receives the GK request from user B, validates that user B
was a member of the GMBC at the time the requested GK was
created, and returns a copy of the GK created in step 3 with the
keying material portion encrypted using the public entity key of
user B.
8. User C repeats the procedure outlined for user B in steps 5
through 7.
5. Primitive Specifications
This section provides normative definition for the objects introduced
in this document.
5.1. Entity
An entity is identified by an acct URI [RFC7565], its associated
public entity key is discovered through key discovery as described in
[I-D.miller-saag-key-discovery], and that key is represented as a JWK
[RFC7517] also as defined in that specification.
5.2. Group Membership Block Chain
A GMBC is composed of JSON encoded blocks, each signed with the
private key of the entity that introduced that block to the chain.
Signing is performed in conformance with the JWS [RFC7515]
specification and the block is communicated between entities in the
form of a JWS compact serialization.
The basic payload of a GMBC block is defined as follows, using JSON
content rules notation [I-D.newton-json-content-rules].
Biggs & Cooley Expires May 6, 2016 [Page 12]
Internet-Draft primitives-for-conf-group-comms November 2015
operation "Operation" {
"entity": uri, ; acct URI of entity added/removed
"optype": < "add" "remove" > ; tag indicating type of operation
}
gmbc-block {
"creator": uri, ; acct URI of creator of the block
"created": date-time, ; date and time of block creation
"operations" [ *: operation ] ; membership update operations
}
A GMBC genesis block is specified as a basic block with three
additional payload fields, as defined below.
gmbc-genesis-block {
"uri": uri, ; URI to identify the GMBC itself
"curator": ?uri, ; (optional) acct URI of curator
"nonce": integer, ; a random one-time numeric value
gmbc-block ; standard block attributes
}
root gmbc-genesis-block
A GMBC non-genesis block is specified as a basic block with one
additional payload field, as defined below.
gmbc-appended-block {
"antecedent": string, ; SHA-256 hash of preceding block
gmbc-block ; standard block attributes
}
root gmbc-appended-block
5.3. Group Key
A GK is composed of JSON encoded blocks, each signed with the private
key of the entity that created it (or the curator when servicing GK
requests in centralized groups). Signing is performed in conformance
with the JWS specification and the block is communicated between
entities in the form of a JWS compact serialization.
The payload of a GK is defined as follows.
Biggs & Cooley Expires May 6, 2016 [Page 13]
Internet-Draft primitives-for-conf-group-comms November 2015
group-key {
"uri": uri, ; URI to identify the GK itself
"creator": uri, ; acct URI of creator of the GK
"created": date-time, ; the date and time of GK creation
"block": string, ; SHA-256 hash of GMBC block
"key": wrapped-key ; encrypted symmetric key material
}
root group-key
The "key" attribute's value is a JWE JSON serialization as defined in
[RFC7516] with one or more recipients (either one recipient for each
member of the group at the time the key was created, or the group
curator). The payload of that JWE is a JWK [RFC7517] representing a
symmetric key.
6. Mandatory-to-Implement
Implementations MUST support the following JWK key types from
[I-D.ietf-jose-json-web-algorithms]:
o "RSA" for entity static public/private key
o "oct" for all symmetric keys
Implementations MUST support "PS256" (RSASSA-PSS using SHA-256 and
MGF1 with SHA-256) from [I-D.ietf-jose-json-web-algorithms] for
signatures using entity static public/private key.
Implementations MUST support "RSA-OAEP" (RSAES OAEP using default
parameters) from [I-D.ietf-jose-json-web-algorithms] for key
encryption using entity static public/private keys.
Implementations MUST support "A256GCM" (AES GCM using 256 bit key)
from [I-D.ietf-jose-json-web-algorithms] for content encryption.
7. Security Considerations
Security considerations are discussed throughout this document.
Additional considerations may be added here as needed.
8. Appendix A. Acknowledgments
This specification is the work of several contributors. In
particular, the following individuals contributed ideas, feedback,
and wording that influenced this specification:
Matt Miller
Biggs & Cooley Expires May 6, 2016 [Page 14]
Internet-Draft primitives-for-conf-group-comms November 2015
9. Appendix B. Document History
-00
o Initial draft.
-01
o Updates to accommodate flows identified in dependent drafts.
10. Normative References
[I-D.ietf-jose-json-web-algorithms]
Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
json-web-algorithms-33 (work in progress), September 2014.
[I-D.miller-saag-key-discovery]
Miller, M. and S. Nandakumar, "Key Discovery Service",
draft-miller-saag-key-discovery-00 (work in progress),
July 2015.
[I-D.newton-json-content-rules]
Newton, A., "A Language for Rules Describing JSON
Content", draft-newton-json-content-rules-02 (work in
progress), August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, May 2015.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, May 2015.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May
2015.
[RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, May
2015.
Biggs & Cooley Expires May 6, 2016 [Page 15]
Internet-Draft primitives-for-conf-group-comms November 2015
Authors' Addresses
Andrew Biggs
Cisco Systems
Email: adb@cisco.com
Shaun Cooley
Cisco Systems
Email: shcooley@cisco.com
Biggs & Cooley Expires May 6, 2016 [Page 16]