Diffie-Hellman Proof-of-Possession Algorithms
RFC 2875
| Document | Type |
RFC
- Proposed Standard
(July 2000)
Obsoleted by RFC 6955
Was
draft-ietf-pkix-dhpop
(pkix WG)
|
|
|---|---|---|---|
| Authors | Jim Schaad, Hemma Prafullchandra | ||
| Last updated | 2013-03-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 2875
Independent Submission R. Alimi
Request for Comments: 7069 Google
Category: Informational A. Rahman
ISSN: 2070-1721 InterDigital Communications, LLC
D. Kutscher
NEC
Y. Yang
Yale University
H. Song
Huawei Technologies
K. Pentikousis
EICT
November 2013
DECoupled Application Data Enroute (DECADE)
Abstract
Content distribution applications, such as those employing peer-to-
peer (P2P) technologies, are widely used on the Internet and make up
a large portion of the traffic in many networks. Often, however,
content distribution applications use network resources
inefficiently. One way to improve efficiency is to introduce storage
capabilities within the network and enable cooperation between end-
host and in-network content distribution mechanisms. This is the
capability provided by a DECoupled Application Data Enroute (DECADE)
system, which is introduced in this document. DECADE enables
applications to take advantage of in-network storage when
distributing data objects as opposed to using solely end-to-end
resources. This document presents the underlying principles and key
functionalities of such a system and illustrates operation through a
set of examples.
Alimi, et al. Informational [Page 1]
RFC 7069 DECADE November 2013
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7069.
Copyright Notice
Copyright (c) 2013 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.
Alimi, et al. Informational [Page 2]
RFC 7069 DECADE November 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Architectural Principles . . . . . . . . . . . . . . . . . . 8
4.1. Data- and Control-Plane Decoupling . . . . . . . . . . . 8
4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . 9
4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 10
4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . 11
4.5. Resource and Data Access Control through Delegation . . . 11
5. System Components . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Application Endpoint . . . . . . . . . . . . . . . . . . 13
5.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 14
5.3. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Data Sequencing and Naming . . . . . . . . . . . . . . . 15
5.5. Token-Based Authorization and Resource Control . . . . . 17
5.6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 18
6. DECADE Protocol Considerations . . . . . . . . . . . . . . . 19
6.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Resource Protocol . . . . . . . . . . . . . . . . . . . . 19
6.3. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 22
6.4. Server-Server Protocols . . . . . . . . . . . . . . . . . 23
6.5. Potential DRP/SDT Candidates . . . . . . . . . . . . . . 23
7. How In-Network Storage Components Map to DECADE . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8.1. Threat: System Denial-of-Service Attacks . . . . . . . . 25
8.2. Threat: Authorization Mechanisms Compromised . . . . . . 25
8.3. Threat: Spoofing of Data Objects . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Evaluation of Candidate Protocols for DECADE DRP/SDT 29
A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. CDMI . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Alimi, et al. Informational [Page 3]
RFC 7069 DECADE November 2013
1. Introduction
Content distribution applications, such as peer-to-peer (P2P)
applications, are widely used on the Internet to distribute data
objects and make up a large portion of the traffic in many networks.
Said applications can often introduce performance bottlenecks in
otherwise well-provisioned networks. In some cases, operators are
forced to invest substantially in infrastructure to accommodate the
use of such applications. For instance, in many subscriber networks,
it can be expensive to upgrade network equipment in the "last mile",
because it can involve replacing equipment and upgrading wiring and
devices at individual homes, businesses, DSLAMs (Digital Subscriber
Line Access Multiplexers), and CMTSs (Cable Modem Termination
Systems) in remote locations. It may be more practical and
economical to upgrade the core infrastructure, instead of the "last
mile" of the network, as this involves fewer components that are
shared by many subscribers. See [RFC6646] and [RFC6392] for a more
complete discussion of the problem domain and general discussions of
the capabilities envisioned for a DECADE system. As a historical
point, it should be noted that [RFC6646] and [RFC6392] came out of
the now closed DECADE Working Group. This document aims to advance
some of the valuable concepts from that now closed Working Group.
This document presents mechanisms for providing in-network storage
that can be integrated into content distribution applications. The
primary focus is P2P-based content distribution, but DECADE may be
useful to other applications with similar characteristics and
requirements (e.g., Content Distribution Networks (CDNs) or hybrid
P2P/CDNs). The approach we adopt in this document is to define the
core functionalities and protocol functions that are needed to
support a DECADE system. This document provides illustrative
examples so that implementers can understand the main concepts in
DECADE, but it is generally assumed that readers are also familiar
with the terms and concepts used in [RFC6646] and [RFC6392].
1.1. Requirements Language
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 RFC 2119 [RFC2119].
Alimi, et al. Informational [Page 4]
RFC 7069 DECADE November 2013
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
This algorithm produces m the value to be signed.
Let L = the size of q (i.e. 2^L <= q < 2^(L+1)). Let M be the
original message to be signed.
1. Compute d = SHA-1(M), the SHA-1 digest of the original message.
2. If L == 160 then m = d.
3. If L > 160 then follow steps (a) through (d) below.
a) Set n = L / 160, where / represents integer division,
consequently, if L = 200, n = 1.
b) Set m = d, the initial computed digest value.
c) For i = 0 to n - 1
m = m | SHA(m), where "|" means concatenation.
d) m = LEFTMOST(m, L-1), where LEFTMOST returns the L-1 left most
bits of m.
Thus the final result of the process meets the criteria that 0 <= m <
q.
4.2 Signature Computation Algorithm
The signature algorithm produces the pair of values (r, s), which is
the signature. The signature is computed as follows:
Given m, the value to be signed, as well as the parameters defined
earlier in section 5.
1. Generate a random or pseudorandom integer k, such that 0 < k^-1 <
q.
2. Compute r = (g^k mod p) mod q.
3. If r is zero, repeat from step 1.
4. Compute s = (k^-1 (m + xr)) mod q.
5. If s is zero, repeat from step 1.
4.3 Signature Verification Algorithm
The signature verification process is far more complicated than is
normal for the Digital Signature Algorithm, as some assumptions about
the validity of parameters cannot be taken for granted.
Prafullchandra & Schaad Standards Track [Page 6]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
Given a message m to be validated, the signature value pair (r, s)
and the parameters for the key.
1. Perform a strong verification that p is a prime number.
2. Perform a strong verification that q is a prime number.
3. Verify that q is a factor of p-1, if any of the above checks fail
then the signature cannot be verified and must be considered a
failure.
4. Verify that r and s are in the range [1, q-1].
5. Compute w = (s^-1) mod q.
6. Compute u1 = m*w mod q.
7. Compute u2 = r*w mod q.
8. Compute v = ((g^u1 * y^u2) mod p) mod q.
9. Compare v and r, if they are the same then the signature verified
correctly.
4.4 ASN Encoding
The signature is encoded using
id-alg-dhPOP OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 4}
The parameters for id-alg-dhPOP are encoded as DomainParameters
(imported from [PROFILE]). The parameters may be omitted in the
signature, as they must exist in the associated key request.
The signature value pair r and s are encoded using Dss-Sig-Value
(imported from [PROFILE]).
5. Security Considerations
In the static DH POP algorithm, an appropriate value can be produced
by either party. Thus this algorithm only provides integrity and not
origination service. The Discrete Logarithm algorithm provides both
integrity checking and origination checking.
Prafullchandra & Schaad Standards Track [Page 7]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
All the security in this system is provided by the secrecy of the
private keying material. If either sender or recipient private keys
are disclosed, all messages sent or received using that key are
compromised. Similarly, loss of the private key results in an
inability to read messages sent using that key.
Selection of parameters can be of paramount importance. In the
selection of parameters one must take into account the
community/group of entities that one wishes to be able to communicate
with. In choosing a set of parameters one must also be sure to avoid
small groups. [FIPS-186] Appendixes 2 and 3 contain information on
the selection of parameters. The practices outlined in this document
will lead to better selection of parameters.
6. References
[FIPS-186] Federal Information Processing Standards Publication
(FIPS PUB) 186, "Digital Signature Standard", 1994 May
19.
[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax
v1.5", RFC 2314, October 1997.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[PROFILE] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL
Profile", RFC 2459, January 1999.
[DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
7. Authors' Addresses
Hemma Prafullchandra
Critical Path Inc.
5150 El Camino Real, #A-32
Los Altos, CA 94022
Phone: (640) 694-6812
EMail: hemma@cp.net
Jim Schaad
EMail: jimsch@exmsft.com
Prafullchandra & Schaad Standards Track [Page 8]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
Appendix A. ASN.1 Module
DH-Sign DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--EXPORTS ALL
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them
-- for their own purposes.
IMPORTS
IssuerAndSerialNumber, MessageDigest
FROM CryptographicMessageSyntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms(1) }
Dss-Sig-Value, DomainParameters
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)};
id-dh-sig-hmac-sha1 OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 3}
DhSigStatic ::= SEQUENCE {
IssuerAndSerial IssuerAndSerialNumber OPTIONAL,
hashValue MessageDigest
}
id-alg-dh-pop OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 4}
END
Prafullchandra & Schaad Standards Track [Page 9]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
Appendix B. Example of Static DH Proof-of-Possession
The following example follows the steps described earlier in section
3.
Step 1: Establishing common Diffie-Hellman parameters. Assume the
parameters are as in the DER encoded certificate. The certificate
contains a DH public key signed by a CA with a DSA signing key.
0 30 939: SEQUENCE {
4 30 872: SEQUENCE {
8 A0 3: [0] {
10 02 1: INTEGER 2
: }
13 02 6: INTEGER
: 00 DA 39 B6 E2 CB
21 30 11: SEQUENCE {
23 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
32 05 0: NULL
: }
34 30 72: SEQUENCE {
36 31 11: SET {
38 30 9: SEQUENCE {
40 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
45 13 2: PrintableString 'US'
: }
: }
49 31 17: SET {
51 30 15: SEQUENCE {
53 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
58 13 8: PrintableString 'XETI Inc'
: }
: }
68 31 16: SET {
70 30 14: SEQUENCE {
72 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4
11)
77 13 7: PrintableString 'Testing'
: }
: }
86 31 20: SET {
88 30 18: SEQUENCE {
90 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
95 13 11: PrintableString 'Root DSA CA'
: }
: }
: }
108 30 30: SEQUENCE {
Prafullchandra & Schaad Standards Track [Page 10]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
110 17 13: UTCTime '990914010557Z'
125 17 13: UTCTime '991113010557Z'
: }
140 30 70: SEQUENCE {
142 31 11: SET {
144 30 9: SEQUENCE {
146 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
151 13 2: PrintableString 'US'
: }
: }
155 31 17: SET {
157 30 15: SEQUENCE {
159 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
164 13 8: PrintableString 'XETI Inc'
: }
: }
174 31 16: SET {
176 30 14: SEQUENCE {
178 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4
11)
183 13 7: PrintableString 'Testing'
: }
: }
192 31 18: SET {
194 30 16: SEQUENCE {
196 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
201 13 9: PrintableString 'DH TestCA'
: }
: }
: }
212 30 577: SEQUENCE {
216 30 438: SEQUENCE {
220 06 7: OBJECT IDENTIFIER dhPublicKey (1 2 840 10046 2 1)
229 30 425: SEQUENCE {
233 02 129: INTEGER
: 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7
: C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82
: F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21
: 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68
: 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72
: 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2
: 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02
: D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85
: 27
365 02 128: INTEGER
: 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90
: 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4
: 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57
Prafullchandra & Schaad Standards Track [Page 11]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
: 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6
: 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE
: 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1
: 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48
: 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD
496 02 33: INTEGER
: 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94
: B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30
: FB
531 02 97: INTEGER
: 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7
: B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D
: AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39
: 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76
: B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56
: 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2
: 92
630 30 26: SEQUENCE {
632 03 21: BIT STRING 0 unused bits
: 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB
: 09 E4 98 34
655 02 1: INTEGER 55
: }
: }
: }
658 03 132: BIT STRING 0 unused bits
: 02 81 80 5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1
: E6 A7 01 4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0
: 46 79 50 A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69
: B7 11 A1 C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22
: 4D 0A 11 6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF
: D8 59 92 C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21
: E1 AF 7A 3A CF 20 0A B4 2C 69 5F CF 79 67 20 31
: 4D F2 C6 ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0
: 8F C5 1A
: }
793 A3 85: [3] {
795 30 83: SEQUENCE {
797 30 29: SEQUENCE {
799 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29
14)
804 04 22: OCTET STRING
: 04 14 80 DF 59 88 BF EB 17 E1 AD 5E C6 40 A3 42
: E5 AC D3 B4 88 78
: }
828 30 34: SEQUENCE {
830 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29
35)
Prafullchandra & Schaad Standards Track [Page 12]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
2. Terminology
This document uses the following terminology.
Application Endpoint
A host that includes a DECADE client along with other application
functionalities (e.g., peer-to-peer (P2P) client, video streaming
client).
Content Distribution Application
A specific type of application that may exist in an Application
Endpoint. A content distribution application is an application
(e.g., P2P) designed for dissemination of large amounts of content
(e.g., files or video streams) to multiple peers. Content
distribution applications may divide content into smaller blocks
for dissemination.
Data Object
A data object is the unit of data stored and retrieved from a
DECADE server. The data object is a sequence of raw bytes. The
server maintains metadata associated with each data object, but
the metadata is physically and logically separate from the data
object.
DECADE Client
A DECADE client uploads and/or retrieves data from a DECADE
server.
DECADE Resource Protocol (DRP)
A logical protocol for communication of access control and
resource-scheduling policies from a DECADE client to a DECADE
server, or between DECADE servers. In practice, the functionality
of the DRP may be distributed over one or more actual protocols.
DECADE Server
A DECADE server stores data inside the network for a DECADE client
or another DECADE server, and thereafter it manages both the
stored data and access to that data by other DECADE clients.
DECADE Storage Provider
A DECADE storage provider deploys and/or manages DECADE servers
within a network.
DECADE System
An in-network storage system that is composed of DECADE clients
and DECADE servers. The DECADE servers may be deployed by one or
more DECADE storage providers.
Alimi, et al. Informational [Page 5]
RFC 7069 DECADE November 2013
In-Network Storage
A service inside a network that provides storage to applications.
In-network storage may reduce upload/transit/backbone traffic and
improve application performance. In-network storage may, for
example, be co-located with the border router (network-attached
storage) or inside a data center. A DECADE system is an example
of an in-network storage system.
Standard Data Transfer (SDT) Protocol
A logical protocol used to transfer data objects between a DECADE
client and DECADE server, or between DECADE servers. The intent
is that in practice the SDT should map to an existing, well-known
protocol already in use over the Internet for transporting data.
3. Overview
A DECADE system provides a distributed storage service for content
distribution applications (e.g., P2P). The system consists of
clients and servers. A client first uploads data objects to one or
more selected servers and optionally requests distribution of these
data objects to other servers. The client then selectively
authorizes other clients to download these data objects. Such a
system is employed in an overall application context (e.g., P2P file
sharing), and it is expected that DECADE clients take part in
application-specific communication sessions.
Figure 1 is a schematic of a simple DECADE system with two DECADE
clients and two DECADE servers. As illustrated, a DECADE client,
which is part of an Application Endpoint, uses the DECADE Resource
Protocol (DRP) to convey to a server information related to access
control and resource-scheduling policies. DRP can also be used
between servers for exchanging this type of information. A DECADE
system employs the Standard Data Transfer (SDT) protocol to transfer
data objects to and from a server, as we will explain later.
Alimi, et al. Informational [Page 6]
RFC 7069 DECADE November 2013
Native Application
Protocol(s)
.-------------. (e.g., P2P) .-------------.
| Application | <------------------> | Application |
| Endpoint | | Endpoint |
| | | |
| .--------. | | .--------. |
| | DECADE | | | | DECADE | |
| | Client | | | | Client | |
| `--------' | | `--------' |
`-------------' `-------------'
| ^ | ^
DECADE | | Standard | |
Resource | | Data DRP | | SDT
Protocol | | Transfer | |
(DRP) | | (SDT) | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
v v v v
.=============. DRP .=============.
| DECADE | <------------------> | DECADE |
| Server | <------------------> | Server |
`=============' SDT `============='
Figure 1: DECADE Overview
With Figure 1 at hand, assume that Application Endpoint B requests a
data object from Application Endpoint A using their native
application protocols (e.g., P2P protocol) as in Figure 2. In this
case, Endpoint A will act as the sender, and Endpoint B as the
receiver for said data object. S(A) is the DECADE storage server
which is access controlled. This means, first, that Endpoint A has a
right to store the data object in S(A). Secondly, Endpoint B needs
to obtain authorization before being able to retrieve the data object
from S(A).
The four steps involved in a DECADE session are illustrated in
Figure 2. The sequence starts with the initial contact between
Endpoint B and Endpoint A, where Endpoint B requests a data object
using their native application protocol (e.g., P2P). Next, Endpoint
A uses DRP to obtain a token corresponding to the data object that
was requested by Endpoint B. There may be several ways for Endpoint
A to obtain such a token, e.g., compute it locally or request one
from its DECADE storage server, S(A). Once obtained, Endpoint A then
Alimi, et al. Informational [Page 7]
RFC 7069 DECADE November 2013
provides the token to Endpoint B (again, using their native
application protocol). Finally, Endpoint B provides the received
token to S(A) via DRP, and subsequently requests and downloads the
data object via SDT. Again, it is assumed that DECADE is employed in
an overall application context (e.g., P2P file-sharing session).
For completeness, note that there is an important prerequisite step
(not shown) to Figure 2, where Endpoint A first discovers and then
stores the data object(s) of interest in S(A).
.----------.
2. Obtain --------> | S(A) | <------
Token / `----------' \ 4. Request and
(DRP) / \ Download
Locally / \ Data Object
or From / \ (DRP + SDT)
S(A) v 1. App Request v
.-------------. <--------------------------- .-------------.
| Application | | Application |
| Endpoint A | | Endpoint B |
`-------------' ---------------------------> `-------------'
3. App Response (token)
Figure 2: Download from Storage Server
4. Architectural Principles
This section presents the key principles followed by any DECADE
system.
4.1. Data- and Control-Plane Decoupling
DECADE SDT and DRP can be classified as belonging to data-plane
functionality. The algorithms and signaling for a P2P application,
for example, would belong to control-plane functionality.
A DECADE system aims to be application independent and should support
multiple content distribution applications. Typically, a complete
content distribution application implements a set of control-plane
functions including content search, indexing and collection, access
control, replication, request routing, and QoS scheduling.
Implementers of different content distribution applications may have
unique considerations when designing the control-plane functions.
For example, with respect to the metadata management scheme,
traditional file systems provide a standard metadata abstraction: a
recursive structure of directories to offer namespace management
where each file is an opaque byte stream. Content distribution
applications may use different metadata management schemes. For
Alimi, et al. Informational [Page 8]
RFC 7069 DECADE November 2013
instance, one application might use a sequence of blocks (e.g., for
file sharing), while another application might use a sequence of
frames (with different sizes) indexed by time.
With respect to resource-scheduling algorithms, a major advantage of
many successful P2P systems is their substantial expertise in
achieving efficient utilization of peer resources. For instance,
many streaming P2P systems include optimization algorithms for
constructing overlay topologies that can support low-latency, high-
bandwidth streaming. The research community as well as implementers
of such systems continuously fine-tune existing algorithms and invent
new ones. A DECADE system should be able to accommodate and benefit
from all new developments.
In short, given the diversity of control-plane functions, a DECADE
system should allow for as much flexibility as possible to the
control plane to implement specific policies (and be decoupled from
data-plane DRP/SDT). Decoupling the control plane from the data
plane is not new, of course. For example, OpenFlow [OpenFlow] is an
implementation of this principle for Internet routing, where the
computation of the forwarding table and the application of the
forwarding table are separated. The Google File System
[GoogleFileSystem] applies the same principle to file system design
by utilizing a Master to handle metadata management and several Chunk
servers to handle data-plane functions (i.e., read and write of
chunks of data). Finally, NFSv4.1's parallel NFS (pNFS) extension
[RFC5661] also adheres to this principle.
4.2. Immutable Data Objects
A common property of bulk content to be broadly distributed is that
it is immutable -- once content is generated, it is typically not
modified. For example, once a movie has been edited and released for
distribution, it is very uncommon that the corresponding video frames
and images need to be modified. The same applies to document
distribution, such as RFCs; audio files, such as podcasts; and
program patches. Focusing on immutable data can substantially
simplify data-plane design, since consistency requirements can be
relaxed. It also simplifies data reuse and the removal of
duplicates.
Depending on its specific requirements, an application may store
immutable data objects in DECADE servers such that each data object
is completely self-contained (e.g., a complete, independently
decodable video segment). An application may also divide data into
data objects that require application-level assembly. Many content
distribution applications divide bulk content into data objects for
multiple reasons, including (a) fetching different data objects from
Alimi, et al. Informational [Page 9]
RFC 7069 DECADE November 2013
different sources in parallel and (b) faster recovery and
verification as individual data objects might be recovered and
verified. Typically, applications use a data object size larger than
a single packet in order to reduce control overhead.
A DECADE system should be agnostic to the nature of the data objects
and should not specify a fixed size for them. A protocol
specification based on this architecture may prescribe requirements
on minimum and maximum sizes for compliant implementations.
Note that immutable data objects can still be deleted. Applications
can support modification of existing data stored at a DECADE server
through a combination of storing new data objects and deleting
existing data objects. For example, a metadata management function
of the control plane might associate a name with a sequence of
immutable data objects. If one of the data objects is modified, the
meta-data management function changes the mapping of the name to a
new sequence of immutable data objects.
4.3. Data Object Identifiers
A data object stored in a DECADE server shall be accessed by DECADE
clients via a data object identifier. Each DECADE client may be able
to access more than one storage server. A data object that is
replicated across different storage servers managed by a storage
provider may be accessed through a single identifier. Since data
objects are immutable, it shall be possible to support persistent
identifiers for data objects.
Data object identifiers should be created by DECADE clients when
uploading the corresponding objects to a DECADE server. The scheme
for the assignment/derivation of the data object identifier to a data
object depends as the data object naming scheme and is out of scope
of this document. One possibility is to name data objects using
hashes as described in [RFC6920]. Note that [RFC6920] describes
naming schemes on a semantic level only, but specific SDTs and DRPs
use specific representations.
In particular, for some applications, it is important that clients
and servers be able to validate the name-object binding, i.e., by
verifying that a received object really corresponds to the name
(identifier) that was used for requesting it (or that was provided by
a sender). If a specific application requires name-object binding
validation, the data object identifiers can support it by providing
message digests or so-called self-certifying naming information.
Alimi, et al. Informational [Page 10]
RFC 7069 DECADE November 2013
Different name-object binding validation mechanisms may be supported
in a single DECADE system. Content distribution applications can
decide what mechanism to use, or to not provide name-object
validation (e.g., if authenticity and integrity can by ascertained by
alternative means). We expect that applications may be able to
construct unique names (with high probability) without requiring a
registry or other forms of coordination. Names may be self-
describing so that a receiving DECADE client understands, for
example, which hash function to use for validating name-object
binding.
Some content distribution applications will derive the name of a data
object from the hash over the data object; this is made possible by
the fact that DECADE objects are immutable. But there may be other
applications such as live streaming where object names will not based
on hashes but rather on an enumeration scheme. The naming scheme
will also enable those applications to construct unique names.
In order to enable the uniqueness, flexibility and self-describing
properties, the naming scheme used in a DECADE system should provide
a "type" field that indicates the name-object validation function
type (for example, "sha-256" [RFC5754]) and the cryptographic data
(such as an object hash) that corresponds to the type information.
Moreover, the naming scheme may additionally provide application or
publisher information.
4.4. Explicit Control
To support the functions of an application's control plane,
applications should be able to keep track and coordinate which data
is stored at particular servers. Thus, in contrast with traditional
caches, applications are given explicit control over the placement
(selection of a DECADE server), deletion (or expiration policy), and
access control for stored data objects. Consider deletion/expiration
policy as a simple example. An application might require that a
DECADE server stores data objects for a relatively short period of
time (e.g., for live-streaming data). Another application might need
to store data objects for a longer duration (e.g., for video on
demand), and so on.
4.5. Resource and Data Access Control through Delegation
A DECADE system provides a shared infrastructure to be used by
multiple Application Endpoints. Thus, it needs to provide both
resource and data access control, as discussed in the following
subsections.
Alimi, et al. Informational [Page 11]
RFC 7069 DECADE November 2013
4.5.1. Resource Allocation
There are two primary interacting entities in a DECADE system.
First, storage providers coordinate DECADE server provisioning,
including their total available resources. Second, applications
coordinate data transfers amongst available DECADE servers and
between servers and clients. A form of isolation is required to
enable each of the concurrently running applications to explicitly
manage its own data objects and share of resources at the available
servers. Therefore, a storage provider should delegate resource
management on a DECADE server to uploading DECADE clients, enabling
them to explicitly and independently manage their own share of
resources on a server.
4.5.2. User Delegation
DECADE storage providers will have the ability to explicitly manage
the entities allowed to utilize the resources available on a DECADE
server. This is needed for reasons such as capacity-planning and
legal considerations in certain deployment scenarios. The DECADE
server should grant a share of the resources to a DECADE client. The
client can in turn share the granted resources amongst its (possibly)
multiple applications. The share of resources granted by a server is
called a User Delegation. As a simple example, a DECADE server
operated by an ISP might be configured to grant each ISP subscriber
1.5 Mbit/s of network capacity and 1 GB of memory. The ISP
subscriber might in turn divide this share of resources amongst a
video-streaming application and file-sharing application that are
running concurrently.
5. System Components
As noted earlier, the primary focus of this document is the
architectural principles and the system components that implement
them. While specific system components might differ between
implementations, this document details the major components and their
overall roles in the architecture. To keep the scope narrow, we only
discuss the primary components related to protocol development.
Particular deployments will require additional components (e.g.,
monitoring and accounting at a server), but they are intentionally
omitted from this document.
Alimi, et al. Informational [Page 12]
RFC 7069 DECADE November 2013
5.1. Application Endpoint
Content distribution applications have many functional components.
For example, many P2P applications have components and algorithms to
manage overlay topology, rate allocation, piece selection, and so on.
In this document, we focus on the components directly engaged in a
DECADE system. Figure 3 illustrates the components discussed in this
section from the perspective of a single Application Endpoint.
Native Application Protocol(s)
(with other Application Endpoints)
.--------------------->
|
V
.----------------------------------------------------------------.
| Application Endpoint |
| .-------------------. .-------------------. |
| | Application-Layer | ... | App Data Assembly | |
| | Algorithms | | Sequencing | |
| `-------------------' `-------------------' |
| |
| .==========================================================. |
| | DECADE Client | |
| | .-------------------------. .--------------------------. | |
| | | Resource Controller | | Data Controller | | |
| | | .--------. .----------. | | .------------. .-------. | | |
| | | | Data | | Resource-| | | | Data | | Data | | | |
| | | | Access | | Sharing | | | | Scheduling | | Index | | | |
| | | | Policy | | Policy | | | | | | | | | |
| | | `--------' `----------' | | `------------' `-------' | | |
| | `-------------------------' `--------------------------' | |
| | | ^ | |
| `== | ============================== | ====================' |
`----- | ------------------------------ | -----------------------'
| |
| DECADE Resource Protocol | Standard Data Transfer
| (DRP) | (SDT)
v V
Figure 3: Application and DECADE Client Components
A DECADE system is geared towards supporting applications that can
distribute content using data objects (e.g., P2P). To accomplish
this, applications can include a component responsible for creating
the individual data objects before distribution and for reassembling
them later. We call this component Application Data Assembly. In
producing and assembling data objects, two important considerations
are sequencing and naming. A DECADE system assumes that applications
Alimi, et al. Informational [Page 13]
RFC 7069 DECADE November 2013
implement this functionality themselves. In addition to DECADE
DRP/SDT, applications will most likely also support other, native
application protocols (e.g., P2P control and data transfer
protocols).
5.2. DECADE Client
The DECADE client provides the local support to an application, and
it can be implemented standalone, embedded into the application, or
integrated in other software entities within network devices (i.e.,
hosts). In general, applications may have different resource-sharing
policies and data access policies with regard to DECADE servers.
These policies may be existing policies of applications or custom
policies. The specific implementation is decided by the application.
Recall that DECADE decouples the control and the data transfer of
applications. A data-scheduling component schedules data transfers
according to network conditions, available servers, and/or available
server resources. The Data Index indicates data available at remote
servers. The Data Index (or a subset of it) can be advertised to
other clients. A common use case for this is to provide the ability
to locate data amongst distributed Application Endpoints (i.e., a
data search mechanism such as a Distributed Hash Table (DHT)).
5.3. DECADE Server
Figure 4 illustrates the primary components of a DECADE server. Note
that the description below does not assume a single-host or
centralized implementation -- a DECADE server is not necessarily a
single physical machine; it can also be implemented in a distributed
manner on a cluster of machines.
Alimi, et al. Informational [Page 14]
RFC 7069 DECADE November 2013
| DECADE Resource | Standard Data
| Protocol (DRP) | Transfer (SDT)
| |
.= | ================= | ===========================.
| | v DECADE Server |
| | .----------------. |
| |----> | Access Control | <--------. |
| | `----------------' | |
| | ^ | |
| | | | |
| | v | |
| | .---------------------. | |
| `-> | Resource Scheduling | <------| |
| `---------------------' | |
| ^ | |
| | | |
| v .-----------------. |
| .-----------------. | User Delegation | |
| | Data Store | | Management | |
| `-----------------' `-----------------' |
`==================================================='
Figure 4: DECADE Server Components
Provided sufficient authorization, a client shall be able to access
its own data or other client's data in a DECADE server. Clients may
also authorize other clients to store data. If access is authorized
by a client, the server should provide access. Applications may
apply resource-sharing policies or use a custom policy. DECADE
servers will then perform resource scheduling according to the
resource-sharing policies indicated by the client as well as any
other previously configured User Delegations. Data from applications
will be stored at a DECADE server. Data may be deleted from storage
either explicitly or automatically (e.g., after a Time To Live (TTL)
expiration).
5.4. Data Sequencing and Naming
The DECADE naming scheme implies no sequencing or grouping of
objects, even if this is done at the application layer. To
illustrate these properties, this section presents several examples
of use.
Alimi, et al. Informational [Page 15]
RFC 7069 DECADE November 2013
5.4.1. Application with Fixed-Size Chunks
Consider an application in which each individual application-layer
segment of data is called a "chunk" and has a name of the form:
"CONTENT_ID:SEQUENCE_NUMBER". Furthermore, assume that the
application's native protocol uses chunks of size 16 KB. Now, assume
that this application wishes to store data in a DECADE server in data
objects of size 64 KB. To accomplish this, it can map a sequence of
4 chunks into a single data object, as shown in Figure 5.
Application Chunks
.---------.---------.---------.---------.---------.---------.--------
| | | | | | |
| Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6
| | | | | | |
`---------`---------`---------`---------`---------`---------`--------
DECADE Data Objects
.---------------------------------------.----------------------------
| |
| Object_0 | Object_1
| |
`---------------------------------------`----------------------------
Figure 5: Mapping Application Chunks to DECADE Data Objects
In this example, the application maintains a logical mapping that is
able to determine the name of a DECADE data object given the chunks
contained within that data object. The name may be conveyed from
either the original uploading DECADE client, another Endpoint with
which the application is communicating, etc. As long as the data
contained within each sequence of chunks is globally unique, the
corresponding data objects have globally unique names.
5.4.2. Application with Continuous Streaming Data
Consider an application whose native protocol retrieves a continuous
data stream (e.g., an MPEG2 stream) instead of downloading and
redistributing chunks of data. Such an application could segment the
continuous data stream to produce either fixed-sized or variable-
sized data objects. Figure 6 depicts how a video streaming
application might produce variable-sized data objects such that each
data object contains 10 seconds of video data. In a manner similar
to the previous example, the application may maintain a mapping that
is able to determine the name of a data object given the time offset
of the video chunk.
Alimi, et al. Informational [Page 16]
RFC 7069 DECADE November 2013
Application's Video Stream
.--------------------------------------------------------------------
|
|
|
`--------------------------------------------------------------------
^ ^ ^ ^ ^
| | | | |
0 seconds 10 seconds 20 seconds 30 seconds 40 seconds
0 B 400 KB 900 KB 1200 KB 1500 KB
DECADE Data Objects
.--------------.--------------.--------------.--------------.--------
| | | | |
| Object_0 | Object_1 | Object_2 | Object_3 |
| (400 KB) | (500 KB) | (300 KB) | (300 KB) |
`--------------`--------------`--------------`--------------`--------
Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects
5.5. Token-Based Authorization and Resource Control
A key feature of a DECADE system is that an Application Endpoint can
authorize other Application Endpoints to store or retrieve data
objects from its in-network storage via tokens. The peer client then
uses the token when sending requests to the DECADE server. Upon
receiving a token, the server validates the signature and the
operation being performed.
This is a simple scheme, but has some important advantages over an
alternative approach, for example, in which a client explicitly
manipulates an Access Control List (ACL) associated with each data
object. In particular, it has the following advantages when applied
to DECADE systems. First, authorization policies are implemented
within the application, thus the Application Endpoint explicitly
controls when tokens are generated, to whom they are distributed, and
for how long they will be valid. Second, fine-grained access and
resource control can be applied to data objects. Third, there is no
messaging between a client and server to manipulate data object
permissions. This can simplify, in particular, applications that
share data objects with many dynamic peers and need to frequently
adjust access control policies attached to data objects. Finally,
tokens can provide anonymous access, in which a server does not need
to know the identity of each client that accesses it. This enables a
client to send tokens to clients belonging to other storage
providers, and to allow them to read or write data objects from the
storage of its own storage provider. In addition to clients' ability
to apply access control policies to data objects, the server may be
Alimi, et al. Informational [Page 17]
RFC 7069 DECADE November 2013
configured to apply additional policies based on user, object
properties, geographic location, etc. A client might thus be denied
access even though it possesses a valid token.
5.6. Discovery
A DECADE system should include a discovery mechanism through which
DECADE clients locate an appropriate DECADE server. A discovery
mechanism should allow a client to determine an IP address or some
other identifier that can be resolved to locate the server for which
the client will be authorized to generate tokens (via DRP). (The
discovery mechanism might also result in an error if no such servers
can be located.) After discovering one or more servers, a DECADE
client can distribute load and requests across them (subject to
resource limitations and policies of the servers themselves)
according to the policies of the Application Endpoint in which it is
embedded. The discovery mechanism outlined here does not provide the
ability to locate arbitrary DECADE servers to which a client might
obtain tokens from others. To do so will require application-level
knowledge, and it is assumed that this functionality is implemented
in the content distribution application.
As noted above, the discovered DECADE server should be authorized to
allow the client to store data objects and then generate tokens to
allow other clients to retrieve these data objects. This
authorization may be:
- a result of off-line administrative procedures;
- access network dependent (e.g., all the subscribers to a
particular ISP may be allowed by the ISP);
- due to a prior subscription;
- etc.
The particular protocol used for discovery is out of scope of this
document, but any specification should reuse well-known protocols
wherever possible.
Alimi, et al. Informational [Page 18]
RFC 7069 DECADE November 2013
6. DECADE Protocol Considerations
This section presents the DRP and the SDT protocol in terms of
abstract protocol interactions that are intended to be mapped to
specific protocols in an implementation. In general, the DRP/SDT
functionality for DECADE client-server interaction is very similar to
that for server-server interaction. Any differences are highlighted
below. DRP is used by a DECADE client to configure the resources and
authorization used to satisfy requests (reading, writing, and
management operations concerning data objects) at a server. SDT will
be used to transport data between a client and a server, as
illustrated in Figure 1.
6.1. Naming
A DECADE system SHOULD use [RFC6920] as the recommended and default
naming scheme. Other naming schemes that meet the guidelines in
Section 4.3 MAY alternatively be used. In order to provide a simple
and generic interface, the DECADE server will be responsible only for
storing and retrieving individual data objects.
The DECADE naming format SHOULD NOT attempt to replace any naming or
sequencing of data objects already performed by an application.
Instead, naming is intended to apply only to data objects referenced
by DECADE-specific purposes. An application using a DECADE client
may use a naming and sequencing scheme independent of DECADE names.
The DECADE client SHOULD maintain a mapping from its own data objects
and their names to the DECADE-specific data objects and names.
Furthermore, the DECADE naming scheme implies no sequencing or
grouping of objects, even if this is done at the application layer.
6.2. Resource Protocol
DRP will provide configuration of access control and resource-sharing
policies on DECADE servers. A content distribution application
(e.g., a live P2P streaming session) can have permission to manage
data at several servers, for instance, servers belonging to different
storage providers. DRP allows one instance of such an application,
i.e., an Application Endpoint, to apply access control and resource-
sharing policies on each of them.
On a single DECADE server, the following resources SHOULD be managed:
a) communication resources in terms of bandwidth (upload/download)
and also in terms of number of active clients (simultaneous
connections); and b) storage resources.
Alimi, et al. Informational [Page 19]
RFC 7069 DECADE November 2013
6.2.1. Access and Resource Control Token
The tokens SHOULD be generated by an entity trusted by both the
DECADE client and the server at the request of a DECADE client. For
example, this entity could be the client, a server trusted by the
client, or another server managed by a storage provider and trusted
by the client. It is important for a server to trust the entity
generating the tokens since each token may incur a resource cost on
the server when used. Likewise, it is important for a client to
trust the entity generating the tokens since the tokens grant access
to the data stored at the server.
The token does not normally include information about the identity of
the authorized client (i.e., it is typically an anonymous token).
However, it is not prohibited to have a binding of the token to an
identity if desired (e.g., binding of the token to the IP address of
the authorized party).
Upon generating a token, a DECADE client can distribute it to another
client. Token confidentiality SHOULD be provided by whatever
protocol it is carried in (i.e., Application Protocol, DRP, or SDT).
The receiving client can then connect to the server specified in the
token and perform any operation permitted by the token. The token
SHOULD be sent along with the operation. The server SHOULD validate
the token to identify the client that issued it and whether the
requested operation is permitted by the contents of the token. If
the token is successfully validated, the server SHOULD apply the
resource control policies indicated in the token while performing the
operation.
Tokens SHOULD include a unique identifier to allow a server to detect
when a token is used multiple times and reject the additional usage
attempts. Since usage of a token incurs resource costs to a server
(e.g., bandwidth and storage) and an uploading DECADE client may have
a limited budget, the uploading DECADE client should be able to
indicate if a token may be used multiple times.
It SHOULD be possible to revoke tokens after they are generated.
This could be accomplished by supplying the server the unique
identifiers of the tokens that are to be revoked.
6.2.2. Status Information
DRP SHOULD provide a status request service that clients can use to
request status information of a server. Access to such status
information SHOULD require client authorization; that is, clients
need to be authorized to access the requested status information.
This authorization is based on the user delegation concept as
Alimi, et al. Informational [Page 20]
RFC 7069 DECADE November 2013
835 01 1: BOOLEAN TRUE
838 04 24: OCTET STRING
: 30 16 80 14 6A 23 37 55 B9 FD 81 EA E8 4E D3 C9
: B7 09 E5 7B 06 E3 68 AA
: }
864 30 14: SEQUENCE {
866 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
871 01 1: BOOLEAN TRUE
874 04 4: OCTET STRING
: 03 02 03 08
: }
: }
: }
: }
880 30 11: SEQUENCE {
882 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
891 05 0: NULL
: }
893 03 48: BIT STRING 0 unused bits
: 30 2D 02 14 7C 6D D2 CA 1E 32 D1 30 2E 29 66 BC
: 06 8B 60 C7 61 16 3B CA 02 15 00 8A 18 DD C1 83
: 58 29 A2 8A 67 64 03 92 AB 02 CE 00 B5 94 6A
: }
Step 2. End Entity/User generates a Diffie-Hellman key-pair using the
parameters from the CA certificate.
EE DH public key: SunJCE Diffie-Hellman Public Key:
Y: 13 63 A1 85 04 8C 46 A8 88 EB F4 5E A8 93 74 AE
FD AE 9E 96 27 12 65 C4 4C 07 06 3E 18 FE 94 B8
A8 79 48 BD 2E 34 B6 47 CA 04 30 A1 EC 33 FD 1A
0B 2D 9E 50 C9 78 0F AE 6A EC B5 6B 6A BE B2 5C
DA B2 9F 78 2C B9 77 E2 79 2B 25 BF 2E 0B 59 4A
93 4B F8 B3 EC 81 34 AE 97 47 52 E0 A8 29 98 EC
D1 B0 CA 2B 6F 7A 8B DB 4E 8D A5 15 7E 7E AF 33
62 09 9E 0F 11 44 8C C1 8D A2 11 9E 53 EF B2 E8
EE DH private key:
X: 32 CC BD B4 B7 7C 44 26 BB 3C 83 42 6E 7D 1B 00
86 35 09 71 07 A0 A4 76 B8 DB 5F EC 00 CE 6F C3
Step 3. Compute K and the signature.
LeadingInfo: DER encoded Subject/Requestor DN (as in the generated
Certificate Signing Request)
Prafullchandra & Schaad Standards Track [Page 13]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
30 4E 31 0B 30 09 06 03 55 04 06 13 02 55 53 31
11 30 0F 06 03 55 04 0A 13 08 58 45 54 49 20 49
6E 63 31 10 30 0E 06 03 55 04 0B 13 07 54 65 73
74 69 6E 67 31 1A 30 18 06 03 55 04 03 13 11 50
4B 49 58 20 45 78 61 6D 70 6C 65 20 55 73 65 72
TrailingInfo: DER encoded Issuer/Recipient DN (from the certificate
described in step 1)
30 46 31 0B 30 09 06 03 55 04 06 13 02 55 53 31
11 30 0F 06 03 55 04 0A 13 08 58 45 54 49 20 49
6E 63 31 10 30 0E 06 03 55 04 0B 13 07 54 65 73
74 69 6E 67 31 12 30 10 06 03 55 04 03 13 09 44
48 20 54 65 73 74 43 41
K:
F4 D7 BB 6C C7 2D 21 7F 1C 38 F7 DA 74 2D 51 AD
14 40 66 75
TBS: the ôtextö for computing the SHA-1 HMAC.
30 82 02 98 02 01 00 30 4E 31 0B 30 09 06 03 55
04 06 13 02 55 53 31 11 30 0F 06 03 55 04 0A 13
08 58 45 54 49 20 49 6E 63 31 10 30 0E 06 03 55
04 0B 13 07 54 65 73 74 69 6E 67 31 1A 30 18 06
03 55 04 03 13 11 50 4B 49 58 20 45 78 61 6D 70
6C 65 20 55 73 65 72 30 82 02 41 30 82 01 B6 06
07 2A 86 48 CE 3E 02 01 30 82 01 A9 02 81 81 00
94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 C5
A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 F5
D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 51
63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 5B
79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 8A
F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 32
E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 D7
B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 27
02 81 80 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87
53 3F 90 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5
0C 53 D4 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6
1B 7F 57 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31
7A 48 B6 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69
D9 9B DE 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33
51 C8 F1 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31
15 26 48 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E
DA D1 CD 02 21 00 E8 72 FA 96 F0 11 40 F5 F2 DC
FD 3B 5D 78 94 B1 85 01 E5 69 37 21 F7 25 B9 BA
71 4A FC 60 30 FB 02 61 00 A3 91 01 C0 A8 6E A4
4D A0 56 FC 6C FE 1F A7 B0 CD 0F 94 87 0C 25 BE
Prafullchandra & Schaad Standards Track [Page 14]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
97 76 8D EB E5 A4 09 5D AB 83 CD 80 0B 35 67 7F
0C 8E A7 31 98 32 85 39 40 9D 11 98 D8 DE B8 7F
86 9B AF 8D 67 3D B6 76 B4 61 2F 21 E1 4B 0E 68
FF 53 3E 87 DD D8 71 56 68 47 DC F7 20 63 4B 3C
5F 78 71 83 E6 70 9E E2 92 30 1A 03 15 00 1C D5
3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB 09 E4
98 34 02 01 37 03 81 84 00 02 81 80 13 63 A1 85
04 8C 46 A8 88 EB F4 5E A8 93 74 AE FD AE 9E 96
27 12 65 C4 4C 07 06 3E 18 FE 94 B8 A8 79 48 BD
2E 34 B6 47 CA 04 30 A1 EC 33 FD 1A 0B 2D 9E 50
C9 78 0F AE 6A EC B5 6B 6A BE B2 5C DA B2 9F 78
2C B9 77 E2 79 2B 25 BF 2E 0B 59 4A 93 4B F8 B3
EC 81 34 AE 97 47 52 E0 A8 29 98 EC D1 B0 CA 2B
6F 7A 8B DB 4E 8D A5 15 7E 7E AF 33 62 09 9E 0F
11 44 8C C1 8D A2 11 9E 53 EF B2 E8
Certification Request:
0 30 793: SEQUENCE {
4 30 664: SEQUENCE {
8 02 1: INTEGER 0
11 30 78: SEQUENCE {
13 31 11: SET {
15 30 9: SEQUENCE {
17 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
22 13 2: PrintableString 'US'
: }
: }
26 31 17: SET {
28 30 15: SEQUENCE {
30 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
35 13 8: PrintableString 'XETI Inc'
: }
: }
45 31 16: SET {
47 30 14: SEQUENCE {
49 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4
11)
54 13 7: PrintableString 'Testing'
: }
: }
63 31 26: SET {
65 30 24: SEQUENCE {
67 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
72 13 17: PrintableString 'PKIX Example User'
: }
: }
Prafullchandra & Schaad Standards Track [Page 15]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
: }
91 30 577: SEQUENCE {
95 30 438: SEQUENCE {
99 06 7: OBJECT IDENTIFIER dhPublicKey (1 2 840 10046 2 1)
108 30 425: SEQUENCE {
112 02 129: INTEGER
: 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7
: C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82
: F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21
: 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68
: 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72
: 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2
: 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02
: D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85
: 27
244 02 128: INTEGER
: 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90
: 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4
: 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57
: 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6
: 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE
: 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1
: 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48
: 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD
375 02 33: INTEGER
: 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94
: B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30
: FB
410 02 97: INTEGER
: 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7
: B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D
: AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39
: 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76
: B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56
: 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2
: 92
509 30 26: SEQUENCE {
511 03 21: BIT STRING 0 unused bits
: 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E
DB
: 09 E4 98 34
534 02 1: INTEGER 55
: }
: }
: }
537 03 132: BIT STRING 0 unused bits
: 02 81 80 13 63 A1 85 04 8C 46 A8 88 EB F4 5E A8
: 93 74 AE FD AE 9E 96 27 12 65 C4 4C 07 06 3E 18
Prafullchandra & Schaad Standards Track [Page 16]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
: FE 94 B8 A8 79 48 BD 2E 34 B6 47 CA 04 30 A1 EC
: 33 FD 1A 0B 2D 9E 50 C9 78 0F AE 6A EC B5 6B 6A
: BE B2 5C DA B2 9F 78 2C B9 77 E2 79 2B 25 BF 2E
: 0B 59 4A 93 4B F8 B3 EC 81 34 AE 97 47 52 E0 A8
: 29 98 EC D1 B0 CA 2B 6F 7A 8B DB 4E 8D A5 15 7E
: 7E AF 33 62 09 9E 0F 11 44 8C C1 8D A2 11 9E 53
: EF B2 E8
: }
: }
672 30 12: SEQUENCE {
674 06 8: OBJECT IDENTIFIER dh-sig-hmac-sha1 (1 3 6 1 5 5 7 6 3)
684 05 0: NULL
: }
686 03 109: BIT STRING 0 unused bits
: 30 6A 30 52 30 48 31 0B 30 09 06 03 55 04 06 13
: 02 55 53 31 11 30 0F 06 03 55 04 0A 13 08 58 45
: 54 49 20 49 6E 63 31 10 30 0E 06 03 55 04 0B 13
: 07 54 65 73 74 69 6E 67 31 14 30 12 06 03 55 04
: 03 13 0B 52 6F 6F 74 20 44 53 41 20 43 41 02 06
: 00 DA 39 B6 E2 CB 04 14 1B 17 AD 4E 65 86 1A 6C
: 7C 85 FA F7 95 DE 48 93 C5 9D C5 24
: }
Signature verification requires CAÆs private key, the CA certificate
and the generated Certification Request.
CA DH private key:
x: 3E 5D AD FD E5 F4 6B 1B 61 5E 18 F9 0B 84 74 a7
52 1E D6 92 BC 34 94 56 F3 0C BE DA 67 7A DD 7D
Prafullchandra & Schaad Standards Track [Page 17]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
Appendix C. Example of Discrete Log Signature
Step 1. Generate a Diffie-Hellman Key with length of q being 256-
bits.
p:
94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 C5
A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 F5
D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 51
63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 5B
79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 8A
F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 32
E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 D7
B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 27
q:
E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94 B1
85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30 FB
g:
26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90
06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4
64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57
86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6
4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE
47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1
39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48
95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD
j:
A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7 B0
CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D AB
83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39 40
9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76 B4
61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56 68
47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2 92
y:
5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1 E6 A7 01
4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0 46 79 50
A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69 B7 11 A1
C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22 4D 0A 11
6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF D8 59 92
C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21 E1 AF 7A
3A CF 20 0A B4 2C 69 5F CF 79 67 20 31 4D F2 C6
ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0 8F C5 1A
seed:
Prafullchandra & Schaad Standards Track [Page 18]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB
09 E4 98 34
C:
00000037
x:
3E 5D AD FD E5 F4 6B 1B 61 5E 18 F9 0B 84 74 a7
52 1E D6 92 BC 34 94 56 F3 0C BE DA 67 7A DD 7D
Step 2. Form the value to be signed and hash with SHA1. The result
of the hash for this example is:
5f a2 69 b6 4b 22 91 22 6f 4c fe 68 ec 2b d1 c6
d4 21 e5 2c
Step 3. The hash value needs to be expanded since |q| = 256. This
is done by hashing the hash with SHA1 and appending it to the
original hash. The value after this step is:
5f a2 69 b6 4b 22 91 22 6f 4c fe 68 ec 2b d1 c6
d4 21 e5 2c 64 92 8b c9 5e 34 59 70 bd 62 40 ad
6f 26 3b f7 1c a3 b2 cb
Next the first 255 bits of this value are taken to be the resulting
"hash" value. Note in this case a shift of one bit right is done
since the result is to be treated as an integer:
2f d1 34 db 25 91 48 91 37 a6 7f 34 76 15 e8 e3
6a 10 f2 96 32 49 45 e4 af 1a 2c b8 5e b1 20 56
Step 4. The signature value is computed. In this case you get the
values
R:
A1 B5 B4 90 01 34 6B A0 31 6A 73 F5 7D F6 5C 14
43 52 D2 10 BF 86 58 87 F7 BC 6E 5A 77 FF C3 4B
S:
59 40 45 BC 6F 0D DC FF 9D 55 40 1E C4 9E 51 3D
66 EF B2 FF 06 40 9A 39 68 75 81 F7 EC 9E BE A1
The encoded signature values is then:
30 45 02 21 00 A1 B5 B4 90 01 34 6B A0 31 6A 73
F5 7D F6 5C 14 43 52 D2 10 BF 86 58 87 F7 BC 6E
5A 77 FF C3 4B 02 20 59 40 45 BC 6F 0D DC FF 9D
55 40 1E C4 9E 51 3D 66 EF B2 FF 06 40 9A 39 68
75 81 F7 EC 9E BE A1
Prafullchandra & Schaad Standards Track [Page 19]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
Result:
30 82 02 c2 30 82 02 67 02 01 00 30 1b 31 19 30
17 06 03 55 04 03 13 10 49 45 54 46 20 50 4b 49
58 20 53 41 4d 50 4c 45 30 82 02 41 30 82 01 b6
06 07 2a 86 48 ce 3e 02 01 30 82 01 a9 02 81 81
00 94 84 e0 45 6c 7f 69 51 62 3e 56 80 7c 68 e7
c5 a9 9e 9e 74 74 94 ed 90 8c 1d c4 e1 4a 14 82
f5 d2 94 0c 19 e3 b9 10 bb 11 b9 e5 a5 fb 8e 21
51 63 02 86 aa 06 b8 21 36 b6 7f 36 df d1 d6 68
5b 79 7c 1d 5a 14 75 1f 6a 93 75 93 ce bb 97 72
8a f0 0f 23 9d 47 f6 d4 b3 c7 f0 f4 e6 f6 2b c2
32 e1 89 67 be 7e 06 ae f8 d0 01 6b 8b 2a f5 02
d7 b6 a8 63 94 83 b0 1b 31 7d 52 1a de e5 03 85
27 02 81 80 26 a6 32 2c 5a 2b d4 33 2b 5c dc 06
87 53 3f 90 06 61 50 38 3e d2 b9 7d 81 1c 12 10
c5 0c 53 d4 64 d1 8e 30 07 08 8c dd 3f 0a 2f 2c
d6 1b 7f 57 86 d0 da bb 6e 36 2a 18 e8 d3 bc 70
31 7a 48 b6 4e 18 6e dd 1f 22 06 eb 3f ea d4 41
69 d9 9b de 47 95 7a 72 91 d2 09 7f 49 5c 3b 03
33 51 c8 f1 39 9a ff 04 d5 6e 7e 94 3d 03 b8 f6
31 15 26 48 95 a8 5c de 47 88 b4 69 3a 00 a7 86
9e da d1 cd 02 21 00 e8 72 fa 96 f0 11 40 f5 f2
dc fd 3b 5d 78 94 b1 85 01 e5 69 37 21 f7 25 b9
ba 71 4a fc 60 30 fb 02 61 00 a3 91 01 c0 a8 6e
a4 4d a0 56 fc 6c fe 1f a7 b0 cd 0f 94 87 0c 25
be 97 76 8d eb e5 a4 09 5d ab 83 cd 80 0b 35 67
7f 0c 8e a7 31 98 32 85 39 40 9d 11 98 d8 de b8
7f 86 9b af 8d 67 3d b6 76 b4 61 2f 21 e1 4b 0e
68 ff 53 3e 87 dd d8 71 56 68 47 dc f7 20 63 4b
3c 5f 78 71 83 e6 70 9e e2 92 30 1a 03 15 00 1c
d5 3a 0d 17 82 6d 0a 81 75 81 46 10 8e 3e db 09
e4 98 34 02 01 37 03 81 84 00 02 81 80 5f cf 39
ad 62 cf 49 8e d1 ce 66 e2 b1 e6 a7 01 4d 05 c2
77 c8 92 52 42 a9 05 a4 db e0 46 79 50 a3 fc 99
3d 3d a6 9b a9 ad bc 62 1c 69 b7 11 a1 c0 2a f1
85 28 f7 68 fe d6 8f 31 56 22 4d 0a 11 6e 72 3a
02 af 0e 27 aa f9 ed ce 05 ef d8 59 92 c0 18 d7
69 6e bd 70 b6 21 d1 77 39 21 e1 af 7a 3a cf 20
0a b4 2c 69 5f cf 79 67 20 31 4d f2 c6 ed 23 bf
c4 bb 1e d1 71 40 2c 07 d6 f0 8f c5 1a a0 00 30
0c 06 08 2b 06 01 05 05 07 06 04 05 00 03 47 00
30 44 02 20 54 d9 43 8d 0f 9d 42 03 d6 09 aa a1
9a 3c 17 09 ae bd ee b3 d1 a0 00 db 7d 8c b8 e4
56 e6 57 7b 02 20 44 89 b1 04 f5 40 2b 5f e7 9c
f9 a4 97 50 0d ad c3 7a a4 2b b2 2d 5d 79 fb 38
8a b4 df bb 88 bc
Prafullchandra & Schaad Standards Track [Page 20]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
Decoded Version of result:
0 30 707: SEQUENCE {
4 30 615: SEQUENCE {
8 02 1: INTEGER 0
11 30 27: SEQUENCE {
13 31 25: SET {
15 30 23: SEQUENCE {
17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
22 13 16: PrintableString 'IETF PKIX SAMPLE'
: }
: }
: }
40 30 577: SEQUENCE {
44 30 438: SEQUENCE {
48 06 7: OBJECT IDENTIFIER dhPublicNumber (1 2 840 10046 2
1)
57 30 425: SEQUENCE {
61 02 129: INTEGER
: 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7
: C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82
: F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21
: 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68
: 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72
: 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2
: 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02
: D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85
: 27
193 02 128: INTEGER
: 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90
: 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4
: 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57
: 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6
: 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE
: 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1
: 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48
: 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD
324 02 33: INTEGER
: 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94
: B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30
: FB
359 02 97: INTEGER
: 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7
: B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D
: AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39
: 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76
: B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56
: 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2
Prafullchandra & Schaad Standards Track [Page 21]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
: 92
458 30 26: SEQUENCE {
460 03 21: BIT STRING 0 unused bits
: 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB
: 09 E4 98 34
483 02 1: INTEGER 55
: }
: }
: }
486 03 132: BIT STRING 0 unused bits
: 02 81 80 5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1
: E6 A7 01 4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0
: 46 79 50 A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69
: B7 11 A1 C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22
: 4D 0A 11 6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF
: D8 59 92 C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21
: E1 AF 7A 3A CF 20 0A B4 2C 69 5F CF 79 67 20 31
: 4D F2 C6 ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0
: 8F C5 1A
: }
621 A0 0: [0]
: }
623 30 12: SEQUENCE {
625 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 6 4'
635 05 0: NULL
: }
637 03 72: BIT STRING 0 unused bits
: 30 45 02 21 00 A1 B5 B4 90 01 34 6B A0 31 6A 73
: F5 7D F6 5C 14 43 52 D2 10 BF 86 58 87 F7 BC 6E
: 5A 77 FF C3 4B 02 20 59 40 45 BC 6F 0D DC FF 9D
: 55 40 1E C4 9E 51 3D 66 EF B2 FF 06 40 9A 39 68
: 75 81 F7 EC 9E BE A1
: }
Prafullchandra & Schaad Standards Track [Page 22]
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Prafullchandra & Schaad Standards Track [Page 23]