9.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:keyprov:container:1.0
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer
(Philip.Hoyer@actividentity.com).
XML Schema: The XML schema to be registered is contained in
Section 8. Its first line is
and its last line is
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:keyprov:container:1.0
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:keyprov:container:1.0", per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:keyprov:container:1.0
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer
(Philip.Hoyer@actividentity.com).
XML:
Hoyer, et al. Expires October 23, 2008 [Page 41]
Internet-Draft Portable Symmetric Key Container April 2008
BEGIN
PSKC Namespace
Namespace for PSKC
urn:ietf:params:xml:ns:keyprov:container:1.0
See RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.].
END
9.4. Symmetric Key Algorithm Identifier Registry
This specification requests the creation of a new IANA registry for
symmetric key cryptographic algorithm identifiers in accordance with
the principles set out in RFC 2434 [RFC2434]as follows:
9.4.1. Applicability
The use of URIs as algorithm identifiers provides an effectively
unlimited namespace. While this eliminates the possibility of
namespace exhaustion it creates a new concern, that divergent
identifiers will be employed for the same purpose in different
contexts.
The key algorithm registry is intended to provide a means of
specifying the canonical identifier to be used for a given algorithm.
If an algorithm has an identifier specified in the registry a
application that is conformant to a protocol specification that
specifies use of that registry to define identifiers SHOULD always
use that particular form of the identifier when originating data. A
conformant application MAY accept other identifiers in data that is
received.
For the sake of expediency, the initial registry only defines
algorithm classes for symmetric algorithms plus cryptographic message
digest functions (one-way hash). While the same principles may be
extended to asymmetric algorithms, doing so would require much
Hoyer, et al. Expires October 23, 2008 [Page 42]
Internet-Draft Portable Symmetric Key Container April 2008
greater consideration of issues such as key length and treatment of
parameters, particularly where eliptic curve cryptography algorithms
are concerned.
As part of this registry the IANA will maintain the following
information:
Common Name The name by which the algorithm is generally referred.
Class The type of algorithm, encryption, Message Authentication Code
(MAC), One Time Pawword (OTP), Digest, etc.
Cannonical URI The cannonical URI to be used to identify the
algorithm.
Algorithm Definition A reference to the document in which the
algorithm described by the identifier is defined.
Identifier Definition A reference to the document in which the use
of the identifier to refer to the algorithm is described. This
would ideally be the document in which the algorithm is defined.
In the case where the registrant does not request a particular
URI, the IANA will assign it a Uniform Resource Name (URN) that
follows RFC 3553 [RFC3553].
Note that where a single algorithm has different forms distinguished
by paremeters such as key length, the algorithm class and each
combination of algorithm parameters may be considered a distinct
algorithm for the purpose of assigning identifiers.
9.4.2. Registerable Algorithms
9.4.2.1. Assigned URIs
If the registrant wishes to have a URI assigned, then a URN of the
form
urn:ietf:params:xml::
will be assigned where is the type of the algorithm being
identified (see below). is a unique id specified by the party
making the request and will normally be either the common name of the
algorithm or an abbreviation thereof.
NOTE: in order for a URN of this type to be assigned, the item being
registered MUST have been through the IETF consensus process.
Basically, this means that it must be documented in a RFC.
Hoyer, et al. Expires October 23, 2008 [Page 43]
Internet-Draft Portable Symmetric Key Container April 2008
NOTE: Expert Review is sufficient in cases where the request does not
require a URN assignment inthe IETF namespace. IETF consensus is not
required.
9.4.2.2. Assigned Classes
Each algorithm MUST belong to an assigned algorithm class. In the
case that additional classes are required these are to be specified
by IETF Consensus action.
The initial assigned classes are:
Digest A cryptographic Digest algorithm.
MAC A Message Authentication Code algorithm.
Symmetric A symmetric encryption algorithm.
OTP A one time password (OTP) algorithm.
9.4.3. Registration Procedures
9.4.3.1. Review
Algorithm identifier registrations are to be subject to Expert Review
as per RFC 2434 [RFC2434].
The need for supporting documentation for the registration depends on
the nature of the request. In the case of a cryptographic algorithm
that is being described for publication as an RFC, the request for a
URI allocation would normally appear within the RFC itself. In the
case of a cryptographic algorithm that is fully and comprehensively
defined in another form, it would not be necessary to duplicate the
information for the sake of issuing the information in the RFC
series. In other cases an RFC may be required in order to ensure
that certain algorithm parameters are sufficiently and unambiguously
defined.
The scope of such expert review is to be strictly limited to
identifying possible ambiguity and/or duplication of existing
identifiers. The expert review MUST NOT consider the cryptographic
properties, intellectual property considerations or any other factor
not related to the use of the identifier.
In reviewing a request, the expert should consider whether other URI
identifiers are already defined for a given algorithm. In such cases
it is the duty of the expert to bring the potential duplication to
the notice of the proposers of the registration and the Security Area
Hoyer, et al. Expires October 23, 2008 [Page 44]
Internet-Draft Portable Symmetric Key Container April 2008
Directors. If the proposers are not willing to accept registration
of the existing identifier the IETF Consensus policy is to apply.
In reviewing a request, the expert should consider whether the
algorithm is sufficiently defined to allow successful interoperation.
In particular the expert should consider whether issues such as key
sizes and byte order are sufficiently defined to allow for
interoperation.
While the defintion requirement MAY be satisifed by a comprehensive
specification of the algorithm, disclosure of the algorithm is not
mandatory.
9.4.3.2. Canonical URI
Until the IANA requests or implements an automated process for the
registration of these elements, any specifications must make that
request part of the IANA considerations section of their respective
documents. That request must be in the form of the following
template:
Common Name The name by which the algorithm is generally referred.
Class The type of algorithm, encryption, Message Authentication Code
(MAC), One Time Pawword (OTP), Digest, etc. As specified by a
defined algorithm class.
URI The cannonical URI to be used to identify the algorithm.
Algorithm Definition A reference to the document in which the
algorithm described by the identifier is defined.
Identifier Definition A reference to the document in which the use
of the identifier to refer to the algorithm is described. This
would ideally be the document in which the algorithm is defined.
Registrant Contact A reference to the document in which the use of
the identifier to refer to the algorithm is described. This would
ideally be the document in which the algorithm is defined.
9.4.3.3. Alias URI
In the case that multiple identifiers have been assigned to the same
identifiers, additional identifiers MAY be registered as aliases. An
entry for an alias contains all the entries for a canonical URI with
the addition of a reference to the canonical URI to be used:
Hoyer, et al. Expires October 23, 2008 [Page 45]
Internet-Draft Portable Symmetric Key Container April 2008
Alias for URI The cannonical URI that identifies the algorithm. The
URI referenced MUST be a canonical URI.
In the case of dispute as to which URI is to be considered canonical
the matter is to be settled by IESG action.
9.4.4. Initial Values
The following initial values are defined. Note that these values are
limited to identifiers that are required by KEYPROV but not specified
elsewhere:
9.4.4.1. HOTP
Common Name: HOTP
Class: OTP
URI: http://www.ietf.org/keyprov/pskc#hotp
Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt
Identifier Definition (this RFC)
Registrant Contact: IESG
9.4.4.2. HOTP-HMAC-SHA-1
Common Name: HOTP-HMAC-SHA-1
Class: OTP
URI: http://www.ietf.org/rfc/rfc4226.txt#HOTP-HMAC-SHA-1
Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt
Identifier Definition (this RFC)
Registrant Contact: IESG
9.4.4.3. KEYPROV-PIN
Common Name: KEYPROV-PIN
Class: Symmetric static credential comparison
Hoyer, et al. Expires October 23, 2008 [Page 46]
Internet-Draft Portable Symmetric Key Container April 2008
URI: http://www.ietf.org/keyprov/pskc#pin
Algorithm Definition: (this document)
Identifier Definition (this document)
Registrant Contact: IESG
9.4.4.4. SecurID-AES
Common Name: SecurID-AES
Class: OTP
URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES
Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821
Identifier Definition http://www.rsa.com/rsalabs/node.asp?id=2821
Registrant Contact: Andrea Doherty, RSA the Security Division of
EMC,
9.4.4.5. SecurID-ALGOR
Common Name: SecurID-ALGOR
Class: OTP
URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-ALGOR
Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821
Identifier Definition http://www.rsa.com/rsalabs/node.asp?id=2821
Registrant Contact: Andrea Doherty, RSA the Security Division of
EMC,
9.4.4.6. ActivIdentity-3DES
Common Name: ActivIdentity-3DES
Class: OTP
Hoyer, et al. Expires October 23, 2008 [Page 47]
Internet-Draft Portable Symmetric Key Container April 2008
URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-3DES
Algorithm Definition: http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-3DES
Identifier Definition http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-3DES
Registrant Contact: Philip Hoyer, ActivIdentity Inc,
9.4.4.7. ActivIdentity-AES
Common Name: ActivIdentity-AES
Class: OTP
URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-AES
Algorithm Definition: http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-AES
Identifier Definition http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-AES
Registrant Contact: Philip Hoyer, ActivIdentity Inc,
9.4.4.8. ActivIdentity-DES
Common Name: ActivIdentity-DES
Class: OTP
URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-DES
Algorithm Definition: http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-DES
Identifier Definition http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-DES
Hoyer, et al. Expires October 23, 2008 [Page 48]
Internet-Draft Portable Symmetric Key Container April 2008
Registrant Contact: Philip Hoyer, ActivIdentity Inc,
9.4.4.9. ActivIdentity-EVENT
Common Name: ActivIdentity-EVENT
Class: OTP
URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-EVENT
Algorithm Definition: http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-EVENT
Identifier Definition http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-EVENT
Registrant Contact: Philip Hoyer, ActivIdentity Inc,
9.5. XML Data Tag Identifier Registry
This specification requests the creation of a new IANA registry for
XML Data Tag identifiers in accordance with the principles set out in
RFC 2434 [RFC2434]as follows:
[More explanation of why an escape to tag value lists is desirable
when inserting unstructured data into an XML schema]
9.5.1. Applicability
As part of this registry the IANA will maintain the following
information:
Common Name Common name for by which the tag is referred to
Cannonical URI The cannonical URI to be employed when citing the
tag.
Data Type The data type of the data that is bound to the tag.
Definition A reference to the document in which the data tag
defined by the identifier is defined.
In the case where the registrant does not request a particular URI,
the IANA will assign it a Uniform Resource Name (URN) that follows
RFC 3553 [RFC3553].
Hoyer, et al. Expires October 23, 2008 [Page 49]
Internet-Draft Portable Symmetric Key Container April 2008
9.5.2. Registerable Data Tags
9.5.2.1. Assigned URIs
If the registrant wishes to have a URI assigned, then a URN of the
form
urn:ietf:params:xml:datatag:
will be assigned where is a unique id specified by the party
making the request and will normally be either the common name of the
tag or an abbreviation thereof.
NOTE: in order for a URN of this type to be assigned, the item being
registered MUST have been through the IETF consensus process.
Basically, this means that it must be documented in a RFC.
NOTE: Expert Review is sufficient in cases where the request does not
require a URN assignment inthe IETF namespace. IETF consensus is not
required.
9.5.3. Registration Procedures
9.5.3.1. Review
Data tag registrations are to be subject to Expert Review as per RFC
2434 [RFC2434].
9.5.3.2. Data Tag Entry
Until the IANA requests or implements an automated process for the
registration of these elements, any specifications must make that
request part of the IANA considerations section of their respective
documents. That request must be in the form of the following
template:
Common Name Common name for by which the tag is referred to
Cannonical URI The cannonical URI to be employed when citing the
tag.
Data Type The data type of the data that is bound to the tag.
Definition A reference to the document in which the data tag
defined by the identifier is defined.
Hoyer, et al. Expires October 23, 2008 [Page 50]
Internet-Draft Portable Symmetric Key Container April 2008
9.5.4. Initial Values
The following initial values are defined. Note that these values are
limited to identifiers that are required by KEYPROV but not specified
elsewhere:
9.5.4.1. Secret
Common Name Secret
Cannonical URI urn:ietf:params:xml:datatag:secret
Data Type binary, base64 encoded
Defined in (this document)
9.5.4.2. Counter
Common Name Counter
Cannonical URI urn:ietf:params:xml:datatag:counter
Data Type 8 bytes unsigned integer in big endian (i.e. network byte
order) form base64 encoded
Defined in (this document)
9.5.4.3. Time
Common Name Time
Cannonical URI urn:ietf:params:xml:datatag:time
Data Type 8 bytes unsigned integer in big endian (i.e. network byte
order) form base64 encoded (Number of seconds since 1970)
Defined in (this document)
9.5.4.4. Time Interval
Common Name Time Interval
Cannonical URI urn:ietf:params:xml:datatag:time_interval
Data Type 8 bytes unsigned integer in big endian (i.e. network byte
order) form base64 encoded.
Hoyer, et al. Expires October 23, 2008 [Page 51]
Internet-Draft Portable Symmetric Key Container April 2008
Defined in (this document)
9.5.4.5. Time Drift
Common Name urn:ietf:params:xml:datatag:time_drift
Cannonical URI Time Drift
Data Type 2 bytes unsigned integer in big endian (i.e. network byte
order) form base64 encoded.
Defined in (this document)
Hoyer, et al. Expires October 23, 2008 [Page 52]
Internet-Draft Portable Symmetric Key Container April 2008
10. Security Considerations
The portable key container carries sensitive information (e.g.,
cryptographic keys) and may be transported across the boundaries of
one secure perimeter to another. For example, a container residing
within the secure perimeter of a back-end provisioning server in a
secure room may be transported across the internet to an end-user
device attached to a personal computer. This means that special care
must be taken to ensure the confidentiality, integrity, and
authenticity of the information contained within.
10.1. Payload confidentiality
By design, the container allows two main approaches to guaranteeing
the confidentiality of the information it contains while transported.
First, the container key data payload may be encrypted.
In this case no transport layer security is required. However,
standard security best practices apply when selecting the strength of
the cryptographic algorithm for payload encryption. Symmetric
cryptographic cipher should be used - the longer the cryptographic
key, the stronger the protection. At the time of this writing both
3DES and AES are mandatory algorithms but 3DES may be dropped in the
relatively near future. Applications concerned with algorithm
longevity are advised to use AES-256-CBC. In cases where the
exchange of encryption keys between the sender and the receiver is
not possible, asymmetric encryption of the secret key payload may be
employed. Similarly to symmetric key cryptography, the stronger the
asymmetric key, the more secure the protection is.
If the payload is encrypted with a method that uses one of the
password-based encryption methods provided above, the payload may be
subjected to password dictionary attacks to break the encryption
password and recover the information. Standard security best
practices for selection of strong encryption passwords apply
[Schneier].
Practical implementations should use PBESalt and PBEIterationCount
when PBE encryption is used. Different PBESalt value per key
container should be used for best protection.
The second approach to protecting the confidentiality of the payload
is based on using transport layer security. The secure channel
established between the source secure perimeter (the provisioning
server from the example above) and the target perimeter (the device
attached to the end-user computer) utilizes encryption to transport
the messages that travel across. No payload encryption is required
Hoyer, et al. Expires October 23, 2008 [Page 53]
Internet-Draft Portable Symmetric Key Container April 2008
in this mode. Secure channels that encrypt and digest each message
provide an extra measure of security, especially when the signature
of the payload does not encompass the entire payload.
Because of the fact that the plain text payload is protected only by
the transport layer security, practical implementation must ensure
protection against man-in-the-middle attacks [Schneier]. Validating
the secure channel end-points is critically important for eliminating
intruders that may compromise the confidentiality of the payload.
10.2. Payload integrity
The portable symmetric key container provides a mean to guarantee the
integrity of the information it contains through digital signatures.
For best security practices, the digital signature of the container
should encompass the entire payload. This provides assurances for
the integrity of all attributes. It also allows verification of the
integrity of a given payload even after the container is delivered
through the communication channel to the target perimeter and channel
message integrity check is no longer possible.
10.3. Payload authenticity
The digital signature of the payload is the primary way of showing
its authenticity. The recipient of the container may use the public
key associated with the signature to assert the authenticity of the
sender by tracing it back to a preloaded public key or certificate.
Note that the digital signature of the payload can be checked even
after the container has been delivered through the secure channel of
communication.
A weaker payload authenticity guarantee may be provided by the
transport layer if it is configured to digest each message it
transports. However, no authenticity verification is possible once
the container is delivered at the recipient end. This approach may
be useful in cases where the digital signature of the container does
not encompass the entire payload.
Hoyer, et al. Expires October 23, 2008 [Page 54]
Internet-Draft Portable Symmetric Key Container April 2008
11. Acknowledgements
The authors of this draft would like to thank the following people
for their contributions and support to make this a better
specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart
Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes
Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, and Anders
Rundgren.
Hoyer, et al. Expires October 23, 2008 [Page 55]
Internet-Draft Portable Symmetric Key Container April 2008
12. Appendix A - Example Symmetric Key Containers
All examples are syntactically correct and compatible with the XML
schema in section 7.
12.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret
Key
ACME
0755225266
AnIssuer
AprkuA==
/4h3rOTeBegJwGpmTTq4F+RlNR0=
2012-12-31T00:00:00
12.2. Symmetric Key Container with a single PIN protected Non-Encrypted
HOTP Secret Key
Hoyer, et al. Expires October 23, 2008 [Page 56]
Internet-Draft Portable Symmetric Key Container April 2008
ACME
0755225266
AnIssuer
AprkuA==
/4h3rOTeBegJwGpmTTq4F+RlNR0=
MTIzNA==
12.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP
Secret Key
Hoyer, et al. Expires October 23, 2008 [Page 57]
Internet-Draft Portable Symmetric Key Container April 2008
PRE_SHARED_KEY
http://www.w3.org/2000/09/xmldsig#hmac-sha1
ACME
0755225266
AnIssuer
AprkuA==
kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=
cwJI898rRpGBytTqCAsegaQqPZA=
12.4. Symmetric Key Container with signature and a single Password-
based Encrypted HOTP Secret Key
Passphrase1
Df3dRAhjGh8=
2000
16
ACME
0755225266
AnIssuer
AprkuA==
rf4dx3rvEPO0vKtKL14NbeVu8nk=
Hoyer, et al. Expires October 23, 2008 [Page 59]
Internet-Draft Portable Symmetric Key Container April 2008
j6lwx3rvEPO0vKtMup4NbeVu8nk=
j6lwx3rvEPO0vKtMup4NbeVu8nk=
CN=KeyProvisioning'R'Us.com,C=US
12345678
12.5. Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
Secret Key
Hoyer, et al. Expires October 23, 2008 [Page 60]
Internet-Draft Portable Symmetric Key Container April 2008
miib
ACME
0755225266
AnIssuer
AprkuA==
rf4dx3rvEPO0vKtKL14NbeVu8nk=
Hoyer, et al. Expires October 23, 2008 [Page 61]
Internet-Draft Portable Symmetric Key Container April 2008
13. References
13.1. Normative References
[PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
Specifications Version 2.0.",
URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
October 1998.
[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
Standard", Version 2.0,
URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997,
.
[RFC2434] Narten, T., "Guidelines for Writing an IANA Considerations
Section in RFCs", RFC 2434, October 1998.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3553] Mealling, M., "An IETF URN Sub-namespace for Registered
Protocol Parameters", RFC 3553, June 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006.
[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
W3C Recommendation, February 2002.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
URL: http://www.w3.org/TR/xmlenc-core/, December 2002.
13.2. Informative References
[CAP] MasterCard International, "Chip Authentication Program
Functional Architecture", September 2004.
Hoyer, et al. Expires October 23, 2008 [Page 62]
Internet-Draft Portable Symmetric Key Container April 2008
[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
"Dynamic Symmetric Key Provisioning Protocol", Internet
Draft Informational, URL: http://www.ietf.org/
internet-drafts/draft-ietf-keyprov-dskpp-03.txt,
February 2008.
[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
O. Ranen, "HOTP: An HMAC-Based One Time Password
Algorithm", RFC 4226,
URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
December 2005.
[NIST-SP800-57]
National Institute of Standards and Technology,
"Recommendation for Key Management - Part I: General
(Revised)", NIST 800-57, URL: http://csrc.nist.gov/
publications/nistpubs/800-57/
sp800-57-Part1-revised2_Mar08-2007.pdf, March 2007.
[OATH] "Initiative for Open AuTHentication",
URL: http://www.openauthentication.org.
[OCRA] MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S.
Bajaj, "OCRA: OATH Challenge Response Algorithm", Internet
Draft Informational, URL: http://www.ietf.org/
internet-drafts/
draft-mraihi-mutual-oath-hotp-variants-06.txt,
December 2007.
[PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange
Syntax Standard", Version 1.0,
URL: http://www.rsasecurity.com/rsalabs/pkcs/.
[Schneier]
Schneier, B., "Secrets and Lies: Digitial Security in a
Networked World", Wiley Computer Publishing, ISBN 0-8493-
8253-7, 2000.
Hoyer, et al. Expires October 23, 2008 [Page 63]
Internet-Draft Portable Symmetric Key Container April 2008
Authors' Addresses
Philip Hoyer
ActivIdentity, Inc.
109 Borough High Street
London, SE1 1NL
UK
Phone: +44 (0) 20 7744 6455
Email: Philip.Hoyer@actividentity.com
Mingliang Pei
VeriSign, Inc.
487 E. Middlefield Road
Mountain View, CA 94043
USA
Phone: +1 650 426 5173
Email: mpei@verisign.com
Salah Machani
Diversinet, Inc.
2225 Sheppard Avenue East
Suite 1801
Toronto, Ontario M2J 5C2
Canada
Phone: +1 416 756 2324 Ext. 321
Email: smachani@diversinet.com
Hoyer, et al. Expires October 23, 2008 [Page 64]
Internet-Draft Portable Symmetric Key Container April 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hoyer, et al. Expires October 23, 2008 [Page 65]