draft-ietf-keyprov-dskpp-13.txt   draft-ietf-keyprov-dskpp-14.txt 
KEYPROV Working Group A. Doherty KEYPROV Working Group A. Doherty
Internet-Draft RSA, The Security Division of EMC Internet-Draft RSA, The Security Division of EMC
Intended status: Standards Track M. Pei Intended status: Standards Track M. Pei
Expires: March 7, 2011 VeriSign, Inc. Expires: March 11, 2011 VeriSign, Inc.
S. Machani S. Machani
Diversinet Corp. Diversinet Corp.
M. Nystrom M. Nystrom
Microsoft Corp. Microsoft Corp.
September 3, 2010 September 7, 2010
Dynamic Symmetric Key Provisioning Protocol (DSKPP) Dynamic Symmetric Key Provisioning Protocol (DSKPP)
draft-ietf-keyprov-dskpp-13.txt draft-ietf-keyprov-dskpp-14.txt
Abstract Abstract
DSKPP is a client-server protocol for initialization (and DSKPP is a client-server protocol for initialization (and
configuration) of symmetric keys to locally and remotely accessible configuration) of symmetric keys to locally and remotely accessible
cryptographic modules. The protocol can be run with or without cryptographic modules. The protocol can be run with or without
private-key capabilities in the cryptographic modules, and with or private-key capabilities in the cryptographic modules, and with or
without an established public-key infrastructure. without an established public-key infrastructure.
Two variations of the protocol support multiple usage scenarios. Two variations of the protocol support multiple usage scenarios.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2011. This Internet-Draft will expire on March 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 20, line 43 skipping to change at page 20, line 43
correctly entered by the user. For example, suppose the AC with correctly entered by the user. For example, suppose the AC with
combined Client ID tag and Password tag is set to combined Client ID tag and Password tag is set to
"108AC00000A20A3582AF0C3E", then the CRC16 calculation would generate "108AC00000A20A3582AF0C3E", then the CRC16 calculation would generate
a checksum of 0x356, resulting in a Checksum TLV of "334D5". The a checksum of 0x356, resulting in a Checksum TLV of "334D5". The
complete AC string in this example would be complete AC string in this example would be
"108AC00000A20A3582AF0C3E3034D5". "108AC00000A20A3582AF0C3E3034D5".
Although this specification recommends using hexadecimal characters Although this specification recommends using hexadecimal characters
only for the AC at the application's user interface layer and making only for the AC at the application's user interface layer and making
the TLV triples non-transparent to the user as described in the the TLV triples non-transparent to the user as described in the
example above; implementations MAY choose to use other printable example above; implementations MAY additionally choose to use other
Unicode characters [UNICODE] at the application's user interface printable Unicode characters [UNICODE] at the application's user
layer in order to meet specific local, context or usability interface layer in order to meet specific local, context or usability
requirements. When non-hexadecimal characters are desired at the requirements. When non-hexadecimal characters are desired at the
user interface layer such as when other printable US-ASCII characters user interface layer such as when other printable US-ASCII characters
or international characters are used, SASLprep [RFC4013] MUST be used or international characters are used, SASLprep [RFC4013] MUST be used
to normalize user input before converting it to a string of to normalize user input before converting it to a string of
hexadecimal characters. For example, if a given application allows hexadecimal characters. For example, if a given application allows
use of any printable US-ASCII characters and extended ASCII use of any printable US-ASCII characters and extended ASCII
characters for Client ID and password fields and the Client ID is set characters for Client ID and password fields and the Client ID is set
to "myclient!D" and associated password is set to "mYpas&#rD", the to "myclient!D" and associated password is set to "mYpas&#rD", the
user enters through the keyboard or other means a Client ID of user enters through the keyboard or other means a Client ID of
"myclient!D" and a password of "mYpas&#rD" in separate form fields or "myclient!D" and a password of "mYpas&#rD" in separate form fields or
 End of changes. 5 change blocks. 
7 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/