PSKC phone conference meeting Minutes 28/10/07

<div>

<div class="Section1">

<p class="MsoNormal"><span lang="EN-GB">Attendees:<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Philip Hoyer, MingPei, Shuh Chang.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Apologies: Phillip Hallam Baker<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Discussed new version of the PSKC schema that Ming
prepared for new version of DSKPP.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>1)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">Missing
URIs, what do we do. Philip proposed adding the one we know. We need to agree
at least on HOTP. Should we define URI in the PSKC document or somewhere else?
Agree to define in PSKC. Ming to send email to Siddhart and David M&rsquo;Raihi
and Phillip Hallam Baker to ask if URI should be defined in PSKC or other specs.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>2)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">Agreed
via emails and reaffirmed that all attributes should be capital &ndash; Ming to
do changes and distribute new schema to the list<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>3)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">Remove
AlgorithmIdentifier (OATH legacy structure) not needed anymore with move to
URIs<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>4)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">How
do we distinguish between HOTP counter and HOTP time based? Is URI enough?
Thinking is yes. ASlo mentioned that time based will have mandatory data
elements such as &lsquo;TIME_INTERVAL&rsquo;<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>5)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">What
about usageType should they be in the data elements? Current thinking is to
keep as explicit XML type.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>6)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">Ming
to do schema changes and reflect changes in the document. Including the examples.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>7)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">Philip
mentioned about concerns from RSA about using PKCS5 and xmlenc, Shuh, Ming to
compose email with cons to spark discussion<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>8)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">What
about using xmlenc encryptionmethod and xmlenc encrypted value? Agreed to take
into consideration but defer to next revision.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>9)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-GB">Ming
to think about PIN transfer proposal, Philip would like to add to this rev.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><span>10)<span>&nbsp;&nbsp; </span></span></span><span lang="EN-GB">We
use next call to decide when to release new rev.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Philip<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">________________________________<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Philip Hoyer</span><span lang="EN-GB"> <p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Senior Architect - Office of
CTO<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">ActivIdentity (UK)<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">109
  Borough High Street</span><span lang="EN-GB"><p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">London</span><span lang="EN-GB"> SE1 1NL<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Telephone: +44 (0) 20 7744
6248<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Direct: +44 (0) 20 7744 6455<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Fax: +44 (0) 20 7744 6249<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Private and confidential:
This message and any attachments may contain<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">privileged / confidential
information. If you are not an intended recipient,<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">you must not copy,
distribute, discuss or take any action in reliance on it.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">If you have received this
communication in error, please notify the sender<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">and delete this message
immediately.</span><span lang="EN-GB"><p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

</div>

</div>

Algorithm Identifiers Interim Drafts

Internet Engineering Task Force                          P. Hallam-Baker
Internet-Draft                                              VeriSign Inc
Intended status: Informational                          November 1, 2007
Expires: May 4, 2008

                  Cryptographic Algorithm Identifiers
               draft-hallambaker-algorithm-identifiers-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 4, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Preferred identifiers for cryptographic algorithms currently in use
   in Internet standards.

Hallam-Baker               Expires May 4, 2008                  [Page 1]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Unkeyed Algorithms  . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Digest Algorithms . . . . . . . . . . . . . . . . . . . . . 3
       2.1.1.  SHA2  . . . . . . . . . . . . . . . . . . . . . . . . . 3
       2.1.2.  RIPEMD-160  . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Symmetric Algorithms  . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Encryption Algorithms . . . . . . . . . . . . . . . . . . . 3
       3.1.1.  Block Ciphers . . . . . . . . . . . . . . . . . . . . . 3
         3.1.1.1.  Triple Data Encryption Algorithm  . . . . . . . . . 3
         3.1.1.2.  Advanced Encryption Standard  . . . . . . . . . . . 4
       3.1.2.  Stream Ciphers  . . . . . . . . . . . . . . . . . . . . 4
         3.1.2.1.  RC4 . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Message Authentication Codes  . . . . . . . . . . . . . . . 4
       3.2.1.  HMAC  . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.3.  One Time Password . . . . . . . . . . . . . . . . . . . . . 5
     3.4.  Combination Modes . . . . . . . . . . . . . . . . . . . . . 5
   4.  Asymmetric Algorithms . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Key Agreement . . . . . . . . . . . . . . . . . . . . . . . 5
       4.1.1.  Diffie-Hellman  . . . . . . . . . . . . . . . . . . . . 5
       4.1.2.  RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  Signature . . . . . . . . . . . . . . . . . . . . . . . . . 6
       4.2.1.  RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     4.3.  Encryption  . . . . . . . . . . . . . . . . . . . . . . . . 6
       4.3.1.  RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  XML Tranformation . . . . . . . . . . . . . . . . . . . . . . . 7
     5.1.  Canonicalization  . . . . . . . . . . . . . . . . . . . . . 7
   6.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Binary  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
       6.1.1.  Base 64 . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

Hallam-Baker               Expires May 4, 2008                  [Page 2]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

1.  Introduction

2.  Unkeyed Algorithms

2.1.  Digest Algorithms

2.1.1.  SHA2

   Standards Document: FIPS???

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [SHA256] [length =256] [uri
   =http://www.w3.org/2001/04/xmlenc#sha256]

   Identifier: [SHA512] [length =512] [uri
   =http://www.w3.org/2001/04/xmlenc#sha512]

   [Identifiers defined in : ]

   Identifier: [DNSSEC Code=2] [length =256]

2.1.2.  RIPEMD-160

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#ripemd160]

3.  Symmetric Algorithms

3.1.  Encryption Algorithms

3.1.1.  Block Ciphers

3.1.1.1.  Triple Data Encryption Algorithm

   Alias: Triple DES

   Standards Document: 800-67

   Standards Document: X9.52

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

Hallam-Baker               Expires May 4, 2008                  [Page 3]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

   Identifier: [Mode =cbc] [uri
   =http://www.w3.org/2001/04/xmlenc#tripledes-cbc]

   Identifier: [Mode =kw] [uri
   =http://www.w3.org/2001/04/xmlenc#kw-tripledes]

3.1.1.2.  Advanced Encryption Standard

   Standards Document: FIPS 197

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [length =128] [Mode =cbc] [uri
   =http://www.w3.org/2001/04/xmlenc#aes128-cbc]

   Identifier: [length =192] [Mode =cbc] [uri
   =http://www.w3.org/2001/04/xmlenc#aes192-cbc]

   Identifier: [length =256] [Mode =cbc] [uri
   =http://www.w3.org/2001/04/xmlenc#aes256-cbc]

   Identifier: [length =128] [Mode =kw] [uri
   =http://www.w3.org/2001/04/xmlenc#kw-aes128]

   Identifier: [length =192] [Mode =kw] [uri
   =http://www.w3.org/2001/04/xmlenc#kw-aes192]

   Identifier: [length =256] [Mode =kw] [uri
   =http://www.w3.org/2001/04/xmlenc#kw-aes256]

3.1.2.   Stream Ciphers

3.1.2.1.  RC4

3.2.  Message Authentication Codes

3.2.1.  HMAC

   Standards Document: RFC2104

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [Mode =SHA1] [uri
   =http://www.w3.org/2000/09/xmldsig#hmac-sha1]

Hallam-Baker               Expires May 4, 2008                  [Page 4]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

3.3.  One Time Password

   No algorithms registered yet.

3.4.  Combination Modes

   No algorithms registered yet.

4.  Asymmetric Algorithms

4.1.  Key Agreement

4.1.1.  Diffie-Hellman

   Standards Document: RFC2631

   Standards Document: X9.42

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#dh]

4.1.2.  RSA

   Standards Document: RFC2437

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [Mode =SHA1] [uri
   =http://www.w3.org/2000/09/xmldsig#rsa-sha1]

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-1_5]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p]

   [Identifiers defined in : ]

   Identifier: [DNSSEC Code=5] [Mode =sha1]

   Identifier: [DNSSEC Code=1] [Mode =md5]

Hallam-Baker               Expires May 4, 2008                  [Page 5]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

4.2.  Signature

4.2.1.  RSA

   Standards Document: RFC2437

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [Mode =SHA1] [uri
   =http://www.w3.org/2000/09/xmldsig#rsa-sha1]

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-1_5]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p]

   [Identifiers defined in : ]

   Identifier: [DNSSEC Code=5] [Mode =sha1]

   Identifier: [DNSSEC Code=1] [Mode =md5]

4.3.  Encryption

4.3.1.  RSA

   Standards Document: RFC2437

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [Mode =SHA1] [uri
   =http://www.w3.org/2000/09/xmldsig#rsa-sha1]

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-1_5]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p]

   [Identifiers defined in : ]

   Identifier: [DNSSEC Code=5] [Mode =sha1]

Hallam-Baker               Expires May 4, 2008                  [Page 6]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

   Identifier: [DNSSEC Code=1] [Mode =md5]

5.  XML Tranformation

5.1.  Canonicalization

   No algorithms registered yet.

6.  Encoding

6.1.  Binary

6.1.1.  Base 64

   Standards Document: Base64

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2000/09/xmldsig#base64]

7.  Security Considerations

   TBS

8.  IANA Considerations

   TBS

9.  Normative References

   [800-67]   "Recommendation for the Triple Data Encryption Algorithm
              (TDEA) Block Cipher", May 2004.

   [CSOR]     "Cryptographic Algorithm Object Registration".

   [FIPS 197]
              "Advanced Encryption Standard (AES)", November 2001.

   [RFC2104]  "HMAC: Keyed-Hashing for Message Authentication",
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

Hallam-Baker               Expires May 4, 2008                  [Page 7]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2437]  "PKCS #1: RSA Cryptography Specifications Version 2.0",
              October 1998.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC2631]  "Diffie-Hellman Key Agreement Method", June 1999.

   [RFC4034]  "".

   [RFC4509]  "".

   [RFC4868]  "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with
              IPsec".

   [X9.42]    "Agreement of Symmetric Keys Using Discrete Logarithm
              Cryptography".

   [X9.52]    "Triple Data Encryption Algorithm Modes of Operation",
              1998.

   [XML-C14]  "XML Canonicalization".

   [XML-XC14]
              "Exclusive XML Canonicalization".

   [xmldsig-core]
              "XML-Signature Syntax and Processing", February 2002.

   [xmlenc-core]
              "XML Encryption Syntax and Processing".

   [xpath]    "XML Path Language (XPath) Version 1.0", November 1999.

   [xslt]     "XSL Transformations (XSLT) Version 1.0", November 16.

Author's Address

   Phillip Hallam-Baker
   VeriSign Inc

   Email: pbaker <at> verisign.com

Hallam-Baker               Expires May 4, 2008                  [Page 8]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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 <at> ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hallam-Baker               Expires May 4, 2008                  [Page 9]


Internet Engineering Task Force                          P. Hallam-Baker
Internet-Draft                                              VeriSign Inc
Intended status: Informational                          November 1, 2007
Expires: May 4, 2008

                  Cryptographic Algorithm Identifiers
               draft-hallambaker-algorithm-identifiers-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 4, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Preferred identifiers for cryptographic algorithms currently in use
   in Internet standards.

Hallam-Baker               Expires May 4, 2008                  [Page 1]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Unkeyed Algorithms  . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Digest Algorithms . . . . . . . . . . . . . . . . . . . . . 3
       2.1.1.  SHA2  . . . . . . . . . . . . . . . . . . . . . . . . . 3
       2.1.2.  RIPEMD-160  . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Symmetric Algorithms  . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Encryption Algorithms . . . . . . . . . . . . . . . . . . . 3
       3.1.1.  Block Ciphers . . . . . . . . . . . . . . . . . . . . . 3
         3.1.1.1.  Triple Data Encryption Algorithm  . . . . . . . . . 3
         3.1.1.2.  Advanced Encryption Standard  . . . . . . . . . . . 4
       3.1.2.  Stream Ciphers  . . . . . . . . . . . . . . . . . . . . 4
         3.1.2.1.  RC4 . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Message Authentication Codes  . . . . . . . . . . . . . . . 4
       3.2.1.  HMAC  . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.3.  One Time Password . . . . . . . . . . . . . . . . . . . . . 5
     3.4.  Combination Modes . . . . . . . . . . . . . . . . . . . . . 5
   4.  Asymmetric Algorithms . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Key Agreement . . . . . . . . . . . . . . . . . . . . . . . 5
       4.1.1.  Diffie-Hellman  . . . . . . . . . . . . . . . . . . . . 5
       4.1.2.  RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  Signature . . . . . . . . . . . . . . . . . . . . . . . . . 6
       4.2.1.  RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     4.3.  Encryption  . . . . . . . . . . . . . . . . . . . . . . . . 6
       4.3.1.  RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  XML Tranformation . . . . . . . . . . . . . . . . . . . . . . . 7
     5.1.  Canonicalization  . . . . . . . . . . . . . . . . . . . . . 7
   6.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Binary  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
       6.1.1.  Base 64 . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

Hallam-Baker               Expires May 4, 2008                  [Page 2]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

1.  Introduction

2.  Unkeyed Algorithms

2.1.  Digest Algorithms

2.1.1.  SHA2

   Standards Document: FIPS???

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [SHA256] [length =256] [uri
   =http://www.w3.org/2001/04/xmlenc#sha256]

   Identifier: [SHA512] [length =512] [uri
   =http://www.w3.org/2001/04/xmlenc#sha512]

   [Identifiers defined in : ]

   Identifier: [DNSSEC Code=2] [length =256]

2.1.2.  RIPEMD-160

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#ripemd160]

3.  Symmetric Algorithms

3.1.  Encryption Algorithms

3.1.1.  Block Ciphers

3.1.1.1.  Triple Data Encryption Algorithm

   Alias: Triple DES

   Standards Document: 800-67

   Standards Document: X9.52

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

Hallam-Baker               Expires May 4, 2008                  [Page 3]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

   Identifier: [Mode =cbc] [uri
   =http://www.w3.org/2001/04/xmlenc#tripledes-cbc]

   Identifier: [Mode =kw] [uri
   =http://www.w3.org/2001/04/xmlenc#kw-tripledes]

3.1.1.2.  Advanced Encryption Standard

   Standards Document: FIPS 197

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [length =128] [Mode =cbc] [uri
   =http://www.w3.org/2001/04/xmlenc#aes128-cbc]

   Identifier: [length =192] [Mode =cbc] [uri
   =http://www.w3.org/2001/04/xmlenc#aes192-cbc]

   Identifier: [length =256] [Mode =cbc] [uri
   =http://www.w3.org/2001/04/xmlenc#aes256-cbc]

   Identifier: [length =128] [Mode =kw] [uri
   =http://www.w3.org/2001/04/xmlenc#kw-aes128]

   Identifier: [length =192] [Mode =kw] [uri
   =http://www.w3.org/2001/04/xmlenc#kw-aes192]

   Identifier: [length =256] [Mode =kw] [uri
   =http://www.w3.org/2001/04/xmlenc#kw-aes256]

3.1.2.   Stream Ciphers

3.1.2.1.  RC4

3.2.  Message Authentication Codes

3.2.1.  HMAC

   Standards Document: RFC2104

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [Mode =SHA1] [uri
   =http://www.w3.org/2000/09/xmldsig#hmac-sha1]

Hallam-Baker               Expires May 4, 2008                  [Page 4]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

3.3.  One Time Password

   No algorithms registered yet.

3.4.  Combination Modes

   No algorithms registered yet.

4.  Asymmetric Algorithms

4.1.  Key Agreement

4.1.1.  Diffie-Hellman

   Standards Document: RFC2631

   Standards Document: X9.42

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#dh]

4.1.2.  RSA

   Standards Document: RFC2437

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [Mode =SHA1] [uri
   =http://www.w3.org/2000/09/xmldsig#rsa-sha1]

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-1_5]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p]

   [Identifiers defined in : ]

   Identifier: [DNSSEC Code=5] [Mode =sha1]

   Identifier: [DNSSEC Code=1] [Mode =md5]

Hallam-Baker               Expires May 4, 2008                  [Page 5]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

4.2.  Signature

4.2.1.  RSA

   Standards Document: RFC2437

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [Mode =SHA1] [uri
   =http://www.w3.org/2000/09/xmldsig#rsa-sha1]

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-1_5]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p]

   [Identifiers defined in : ]

   Identifier: [DNSSEC Code=5] [Mode =sha1]

   Identifier: [DNSSEC Code=1] [Mode =md5]

4.3.  Encryption

4.3.1.  RSA

   Standards Document: RFC2437

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [Mode =SHA1] [uri
   =http://www.w3.org/2000/09/xmldsig#rsa-sha1]

   [Identifiers defined in xmlenc-core: XML Encryption Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-1_5]

   Identifier: [uri =http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p]

   [Identifiers defined in : ]

   Identifier: [DNSSEC Code=5] [Mode =sha1]

Hallam-Baker               Expires May 4, 2008                  [Page 6]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

   Identifier: [DNSSEC Code=1] [Mode =md5]

5.  XML Tranformation

5.1.  Canonicalization

   No algorithms registered yet.

6.  Encoding

6.1.  Binary

6.1.1.  Base 64

   Standards Document: Base64

   [Identifiers defined in xmldsig-core: XML-Signature Syntax and
   Processing]

   Identifier: [uri =http://www.w3.org/2000/09/xmldsig#base64]

7.  Security Considerations

   TBS

8.  IANA Considerations

   TBS

9.  Normative References

   [800-67]   "Recommendation for the Triple Data Encryption Algorithm
              (TDEA) Block Cipher", May 2004.

   [CSOR]     "Cryptographic Algorithm Object Registration".

   [FIPS 197]
              "Advanced Encryption Standard (AES)", November 2001.

   [RFC2104]  "HMAC: Keyed-Hashing for Message Authentication",
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

Hallam-Baker               Expires May 4, 2008                  [Page 7]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2437]  "PKCS #1: RSA Cryptography Specifications Version 2.0",
              October 1998.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC2631]  "Diffie-Hellman Key Agreement Method", June 1999.

   [RFC4034]  "".

   [RFC4509]  "".

   [RFC4868]  "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with
              IPsec".

   [X9.42]    "Agreement of Symmetric Keys Using Discrete Logarithm
              Cryptography".

   [X9.52]    "Triple Data Encryption Algorithm Modes of Operation",
              1998.

   [XML-C14]  "XML Canonicalization".

   [XML-XC14]
              "Exclusive XML Canonicalization".

   [xmldsig-core]
              "XML-Signature Syntax and Processing", February 2002.

   [xmlenc-core]
              "XML Encryption Syntax and Processing".

   [xpath]    "XML Path Language (XPath) Version 1.0", November 1999.

   [xslt]     "XSL Transformations (XSLT) Version 1.0", November 16.

Author's Address

   Phillip Hallam-Baker
   VeriSign Inc

   Email: pbaker <at> verisign.com

Hallam-Baker               Expires May 4, 2008                  [Page 8]

Internet-Draft     Cryptographic Algorithm Identifiers     November 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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 <at> ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hallam-Baker               Expires May 4, 2008                  [Page 9]


[Fwd: I-D Action:draft-hallambaker-algorithm-identifiers-00.txt]

FYI

-------- Original Message --------
Subject: 	I-D Action:draft-hallambaker-algorithm-identifiers-00.txt
Date: 	Sun, 04 Nov 2007 22:20:01 -0500
From: 	Internet-Drafts@...
Reply-To: 	internet-drafts@...
To: 	i-d-announce@...

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Cryptographic Algorithm Identifiers
	Author(s)       : P. Hallam-Baker
	Filename        : draft-hallambaker-algorithm-identifiers-00.txt
	Pages           : 9
	Date            : 2007-11-04

Preferred identifiers for cryptographic algorithms currently in use
in Internet standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hallambaker-algorithm-identifiers-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@... with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-hallambaker-algorithm-identifiers-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@...
In the body type:
	"FILE /internet-drafts/draft-hallambaker-algorithm-identifiers-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

RE: [issue28] How to transfer initial PIN to aclientviaPSKC?

Philip,

Thank you for your proposal.  Here are a few comments:

1. By <AccessRules userPIN="true"/> do you mean "PIN is enabled"?  Is
the reverse true, that <AccessRules userPIN="false"/> indicates PINless
operation from a server's point of view? 

2. Instead of <UserPIN position="APPEND/PREPEND"/>, providing a
PINUsageModeType would be more extensible and implementable:
<xs:complexType name="PINUsageModeType">
	<xs:choice maxOccurs="unbounded">
		<xs:element name="Local"/>
		<xs:element name="Prepend"/>
		<xs:element name="Embed"/>
	</xs:choice>
</xs:complexType>

3. Anders brought to my attention that a local PIN is needed instead of
a server PIN in some scenarios.  The device issuer, in this case, would
also have a PIN policy that could differ from the policy of a server
PIN.  Anders provided the following example, which is taken from another
standardization effort in the workings ("PKI for Web 2.0"):

// The following is sent down to the client by the issuer:

<KeyGenerationRequest ...>

// Request a key without PIN protection.

  <RequestedKey ID="Key.1" KeyUsage="encryption">
    <KeyAlgorithmData>
      <RSA KeySize="2048"/>
    </KeyAlgorithmData>
  </RequestedKey>

// Request a set of keys with PIN protection.
// The specified policy disallows 11122 but accepts 11223
// 654321 would not be accepted either (sequence)

  <PINProtection Type="numeric" MinLength="5" MaxLength="8"
                 PatternRestrictions="three-in-a-row  sequences">

// The next element is optional and is a way of grouping PINs
// so that the user either only has to specify a single PIN
// for a set of keys, or one unique PIN per key.

    <PINGroupProtection Shared="true">

      <RequestedKey ID="Key.2" KeyUsage="signature">
        <KeyAlgorithmData>
          <RSA KeySize="2048"/>
        </KeyAlgorithmData>
      </RequestedKey>
      <RequestedKey ID="Key.3" KeyUsage="authentication">
        <KeyAlgorithmData>
          <RSA KeySize="2048"/>
        </KeyAlgorithmData>
      </RequestedKey>

    </PINGroupProtection>

  </PINProtection>

</KeyGenerationRequest>

Your thoughts?
Andrea 

-----Original Message-----
From: Philip Hoyer [mailto:philip.hoyer@...] 
Sent: Thursday, October 18, 2007 6:16 AM
To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@...
Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to
aclientviaPSKC?

Andrea,
You are right I have not addressed the Pin policy issue.

I would like to though. 

Since you seem to have a good idea of the requirements would you be able
to help?

I suggest we create a new type called PINPolicy that contains the data
required to be submitted.

So currently PIN usage I can think of is:
-KEY_ACCESS_CHECK (this check the pin on the device to allow access to a
key for algorithms)
-USED_IN_ALGO (used during calculation)

When you talk though about length I already have that in the <Usage>
part of the PIN 'key' see below

NEW->
       <Key KeyAlgorithm="userPIN"  KeyId="12345678">
         <Issuer>Credential Issuer</Issuer>
         <Usage>
          <ResponseFormat format="DECIMAL" length="4"/>
         </Usage>
         <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>
         <Data Name="SECRET">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
       </Key>
<-NEW

Also when we talk about server verified pins in otps are we not really
talking about the otp algo or usage here?

I was wondering hence if our usage element for the otp key should be
augmented to contain and optional

<UserPIN position="APPEND/PREPEND"/>

What do you think?

Philip

-----Original Message-----
From: Doherty, Andrea [mailto:adoherty@...] 
Sent: Thursday, October 18, 2007 1:28 AM
To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@...
Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a
clientviaPSKC?

Philip,
This looks ok except that a more complex PIN policy is needed (refer to
this comment I made to the previous version of the PSKC draft, Section
5.1.7:
"Recommend that you allow for a more complex PIN policy, esp., (a) how
the PIN is to be used in the OTP calculation (e.g., concatenated vs.
XOR's with the token code) and (b) PIN length. "

This doesn't seem to have been addressed yet based on feedback to my
review (see attached) and example below.  What is the status of this?  
Andrea

-----Original Message-----
From: Philip Hoyer [mailto:philip.hoyer@...] 
Sent: Friday, September 28, 2007 11:48 AM
To: KEYPROV Roundup Issue Tracker; keyprov@...
Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a
clientviaPSKC?

Gentlemen,
Since PSKC will be used also to bulk provision from manufacturing to a
validation server and some of these devices do have a PIN pad there is
the concept of an initial PIN.

Since we have not yet defined how this initial PIN is transmitted in the
PSKC spec I would like to put forward a proposal for inclusion in the
spec for specifying the transmission of PINs.

The PIN is effectively another shared secret hence I propose to treat it
as a key in itself.

This has the advantage that we can leverage the Usage part of the schema
that can define things like length and format (alphanumeric etc). we
also can set an expiry etc. It also leverages the fact that the PIN
itself will be encrypted in transport in the same manner as other key
material.

I hence propose to extend the KeyAlgorithmType with a new type called
'userPIN' (inline with the name used in the access rules element already
present)

As an example a KeyContainer with a non encrypted HOTP key and a 4 digit
numeric PIN (please note that the value and valuedigest are just copy
and paste) ( I put the new section with NEW-> and <-NEW lines before and
after):

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer
   xmlns="urn:ietf:params:xml:ns:keyprov:container"
   xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container"
.\keyprov_pskc_schema_v1.1.xsd" version="1.1">
     <EncryptionMethod algorithm="NONE"/>
     <DigestMethod algorithm="HMAC-SHA1"></DigestMethod>
     <Device>
       <DeviceId>
         <Manufacturer>Token Manufacturer</Manufacturer>
         <SerialNo>98765432187</SerialNo>
         <Expiry>01/01/2008</Expiry>
       </DeviceId>
       <Key KeyAlgorithm="HOTP"  KeyId="98765432187">
         <Issuer>Credential Issuer</Issuer>
         <Usage>
          <ResponseFormat format="DECIMAL" length="6"/>
         </Usage>
NEW->
         <AccessRules userPIN="true"/>
<-NEW
         <FriendlyName>MyFirstToken</FriendlyName>
         <Data Name="SECRET">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
         <Data Name="COUNTER">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
       </Key>
NEW->
       <Key KeyAlgorithm="userPIN"  KeyId="12345678">
         <Issuer>Credential Issuer</Issuer>
         <Usage>
          <ResponseFormat format="DECIMAL" length="4"/>
         </Usage>
         <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>
         <Data Name="SECRET">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
       </Key>
<-NEW
     </Device>
   </KeyContainer>

Comments are welcome,

Philip

-----Original Message-----
From: Mingliang Pei [mailto:hannes.tschofenig@...] 
Sent: Friday, September 21, 2007 9:58 AM
To: keyprov@...
Subject: [KEYPROV] [issue28] How to transfer initial PIN to a client
viaPSKC?

New submission from Mingliang Pei <mpei@...>:

PSKC provies support about carrying PIN usage policy. When PIN is used,
how do 
you actually transfer the initial PIN using PSKC? Should PIN be treated
as 
another credential, for example?

----------
assignedto: mpei
messages: 71
nosy: keyprov, mpei
priority: critical
status: chatting
title: How to transfer initial PIN to a client via PSKC?

_________________________________________________________
KEYPROV Roundup Issue Tracker <hannes.tschofenig@...>
<http://www.tschofenig.com:8080/keyprov/issue28>
_________________________________________________________

_______________________________________________
KEYPROV mailing list
KEYPROV@...
https://www1.ietf.org/mailman/listinfo/keyprov

_______________________________________________
KEYPROV mailing list
KEYPROV@...
https://www1.ietf.org/mailman/listinfo/keyprov

_______________________________________________
KEYPROV mailing list
KEYPROV@...
https://www1.ietf.org/mailman/listinfo/keyprov

RE: [issue28] How to transfer initial PIN to aclientviaPSKC?

I have chatted with Philip / Salah about my comments this afternoon
while I was almost done my reply of this email. I sent it anyway now for
broad review. Our meeting minutes from Philip later will contain other
proposed changes in our discussion.

1. A PIN is associated with a key; we need to define a better way to
associate with them when we carry PIN in a separate Key type.

- The current proposal assumes that all keys in the same "Device" type
will associate to the PIN credential in the same Device.
- This has a limitation for "PREPEND" case where a device may have
multiple keys, and each key has its own PIN as part of server
authentication.

2. There is use case when a PIN is per device, instead of per key, for
the "Local" access usage. 

So I prefer defining PIN credential inside DeviceType, and refered by
KeyType by an attribute or element, and DeviceType.

3. PIN policy is fine to have its own type. The AccessRule and
PINUsageModeType should combine to be a PIN usage policy. If we are
treating PIN as a separate credential, it is more consistent to make PIN
usage policy part of Usage, I think.

Thanks,

- Ming

> -----Original Message-----
> From: Doherty, Andrea [mailto:adoherty@...] 
> Sent: Thursday, November 08, 2007 12:31 PM
> To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@...
> Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell
> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN 
> to aclientviaPSKC?
> 
> Philip,
> 
> Thank you for your proposal.  Here are a few comments:
> 
> 1. By <AccessRules userPIN="true"/> do you mean "PIN is 
> enabled"?  Is the reverse true, that <AccessRules 
> userPIN="false"/> indicates PINless operation from a server's 
> point of view? 
> 
> 2. Instead of <UserPIN position="APPEND/PREPEND"/>, providing 
> a PINUsageModeType would be more extensible and implementable:
> <xs:complexType name="PINUsageModeType">
> 	<xs:choice maxOccurs="unbounded">
> 		<xs:element name="Local"/>
> 		<xs:element name="Prepend"/>
> 		<xs:element name="Embed"/>
> 	</xs:choice>
> </xs:complexType>
> 
> 3. Anders brought to my attention that a local PIN is needed 
> instead of a server PIN in some scenarios.  The device 
> issuer, in this case, would also have a PIN policy that could 
> differ from the policy of a server PIN.  Anders provided the 
> following example, which is taken from another 
> standardization effort in the workings ("PKI for Web 2.0"):
> 
> // The following is sent down to the client by the issuer:
> 
> <KeyGenerationRequest ...>
> 
> // Request a key without PIN protection.
> 
>   <RequestedKey ID="Key.1" KeyUsage="encryption">
>     <KeyAlgorithmData>
>       <RSA KeySize="2048"/>
>     </KeyAlgorithmData>
>   </RequestedKey>
> 
> // Request a set of keys with PIN protection.
> // The specified policy disallows 11122 but accepts 11223 // 
> 654321 would not be accepted either (sequence)
> 
>   <PINProtection Type="numeric" MinLength="5" MaxLength="8"
>                  PatternRestrictions="three-in-a-row  sequences">
> 
> // The next element is optional and is a way of grouping PINs 
> // so that the user either only has to specify a single PIN 
> // for a set of keys, or one unique PIN per key.
> 
>     <PINGroupProtection Shared="true">
> 
>       <RequestedKey ID="Key.2" KeyUsage="signature">
>         <KeyAlgorithmData>
>           <RSA KeySize="2048"/>
>         </KeyAlgorithmData>
>       </RequestedKey>
>       <RequestedKey ID="Key.3" KeyUsage="authentication">
>         <KeyAlgorithmData>
>           <RSA KeySize="2048"/>
>         </KeyAlgorithmData>
>       </RequestedKey>
> 
>     </PINGroupProtection>
> 
>   </PINProtection>
> 
> </KeyGenerationRequest>
> 
> Your thoughts?
> Andrea 
> 
> -----Original Message-----
> From: Philip Hoyer [mailto:philip.hoyer@...]
> Sent: Thursday, October 18, 2007 6:16 AM
> To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@...
> Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell
> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN 
> to aclientviaPSKC?
> 
> Andrea,
> You are right I have not addressed the Pin policy issue.
> 
> I would like to though. 
> 
> Since you seem to have a good idea of the requirements would 
> you be able to help?
> 
> I suggest we create a new type called PINPolicy that contains 
> the data required to be submitted.
> 
> So currently PIN usage I can think of is:
> -KEY_ACCESS_CHECK (this check the pin on the device to allow 
> access to a key for algorithms) -USED_IN_ALGO (used during 
> calculation)
> 
> When you talk though about length I already have that in the 
> <Usage> part of the PIN 'key' see below
> 
> NEW->
>        <Key KeyAlgorithm="userPIN"  KeyId="12345678">
>          <Issuer>Credential Issuer</Issuer>
>          <Usage>
>           <ResponseFormat format="DECIMAL" length="4"/>
>          </Usage>
>          <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>
>          <Data Name="SECRET">
>            <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
>            <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
>          </Data>
>        </Key>
> <-NEW
> 
> Also when we talk about server verified pins in otps are we 
> not really talking about the otp algo or usage here?
> 
> I was wondering hence if our usage element for the otp key 
> should be augmented to contain and optional
> 
> <UserPIN position="APPEND/PREPEND"/>
> 
> What do you think?
> 
> Philip
> 
> 
> -----Original Message-----
> From: Doherty, Andrea [mailto:adoherty@...]
> Sent: Thursday, October 18, 2007 1:28 AM
> To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@...
> Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN 
> to a clientviaPSKC?
> 
> Philip,
> This looks ok except that a more complex PIN policy is needed 
> (refer to this comment I made to the previous version of the 
> PSKC draft, Section
> 5.1.7:
> "Recommend that you allow for a more complex PIN policy, 
> esp., (a) how the PIN is to be used in the OTP calculation 
> (e.g., concatenated vs.
> XOR's with the token code) and (b) PIN length. "
> 
> This doesn't seem to have been addressed yet based on 
> feedback to my review (see attached) and example below.  What 
> is the status of this?  
> Andrea
> 
> -----Original Message-----
> From: Philip Hoyer [mailto:philip.hoyer@...]
> Sent: Friday, September 28, 2007 11:48 AM
> To: KEYPROV Roundup Issue Tracker; keyprov@...
> Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN 
> to a clientviaPSKC?
> 
> Gentlemen,
> Since PSKC will be used also to bulk provision from 
> manufacturing to a validation server and some of these 
> devices do have a PIN pad there is the concept of an initial PIN.
> 
> Since we have not yet defined how this initial PIN is 
> transmitted in the PSKC spec I would like to put forward a 
> proposal for inclusion in the spec for specifying the 
> transmission of PINs.
> 
> The PIN is effectively another shared secret hence I propose 
> to treat it as a key in itself.
> 
> This has the advantage that we can leverage the Usage part of 
> the schema that can define things like length and format 
> (alphanumeric etc). we also can set an expiry etc. It also 
> leverages the fact that the PIN itself will be encrypted in 
> transport in the same manner as other key material.
> 
> I hence propose to extend the KeyAlgorithmType with a new 
> type called 'userPIN' (inline with the name used in the 
> access rules element already
> present)
> 
> 
> As an example a KeyContainer with a non encrypted HOTP key 
> and a 4 digit numeric PIN (please note that the value and 
> valuedigest are just copy and paste) ( I put the new section 
> with NEW-> and <-NEW lines before and
> after):
> 
>    <?xml version="1.0" encoding="UTF-8"?>
>    <KeyContainer
>    xmlns="urn:ietf:params:xml:ns:keyprov:container"
>    xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo"
>    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container"
> .\keyprov_pskc_schema_v1.1.xsd" version="1.1">
>      <EncryptionMethod algorithm="NONE"/>
>      <DigestMethod algorithm="HMAC-SHA1"></DigestMethod>
>      <Device>
>        <DeviceId>
>          <Manufacturer>Token Manufacturer</Manufacturer>
>          <SerialNo>98765432187</SerialNo>
>          <Expiry>01/01/2008</Expiry>
>        </DeviceId>
>        <Key KeyAlgorithm="HOTP"  KeyId="98765432187">
>          <Issuer>Credential Issuer</Issuer>
>          <Usage>
>           <ResponseFormat format="DECIMAL" length="6"/>
>          </Usage>
> NEW->
>          <AccessRules userPIN="true"/>
> <-NEW
>          <FriendlyName>MyFirstToken</FriendlyName>
>          <Data Name="SECRET">
>            <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
>            <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
>          </Data>
>          <Data Name="COUNTER">
>            <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
>            <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
>          </Data>
>        </Key>
> NEW->
>        <Key KeyAlgorithm="userPIN"  KeyId="12345678">
>          <Issuer>Credential Issuer</Issuer>
>          <Usage>
>           <ResponseFormat format="DECIMAL" length="4"/>
>          </Usage>
>          <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>
>          <Data Name="SECRET">
>            <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
>            <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
>          </Data>
>        </Key>
> <-NEW
>      </Device>
>    </KeyContainer>
> 
> Comments are welcome,
> 
> Philip
> 
> -----Original Message-----
> From: Mingliang Pei [mailto:hannes.tschofenig@...]
> Sent: Friday, September 21, 2007 9:58 AM
> To: keyprov@...
> Subject: [KEYPROV] [issue28] How to transfer initial PIN to a 
> client viaPSKC?
> 
> 
> New submission from Mingliang Pei <mpei@...>:
> 
> PSKC provies support about carrying PIN usage policy. When 
> PIN is used,
> how do 
> you actually transfer the initial PIN using PSKC? Should PIN 
> be treated
> as 
> another credential, for example?
> 
> ----------
> assignedto: mpei
> messages: 71
> nosy: keyprov, mpei
> priority: critical
> status: chatting
> title: How to transfer initial PIN to a client via PSKC?
> 
> _________________________________________________________
> KEYPROV Roundup Issue Tracker <hannes.tschofenig@...>
> <http://www.tschofenig.com:8080/keyprov/issue28>
> _________________________________________________________
> 
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@...
> https://www1.ietf.org/mailman/listinfo/keyprov
> 
> 
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@...
> https://www1.ietf.org/mailman/listinfo/keyprov
> 
> 
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@...
> https://www1.ietf.org/mailman/listinfo/keyprov
> 
> 
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@...
> https://www1.ietf.org/mailman/listinfo/keyprov
> 

[PSKC] Conference call minutes 11/12/07

<div>

<div class="Section1">

<p class="MsoNormal"><span lang="EN-GB">Attendees: MingPei, Salah Machhani, Philip Hoyer<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<ul type="disc">
<li class="MsoNormal"><span lang="EN-GB">Discussion about PIN
     provisioning , [Ming] PIN is a credential but to which key does it belong?
     Do we need to build correlation between to key and pin. Current Philip
     proposal allows only one PIN per device. Ming proposed put PIN within key.
     But what happens if we only need to transmit PINs and no key value? Create
     PIN schema object that uses UsageType replaces access rules and can be set
     at Device and key level. Philip raises that this is a lot of work. So
     create a PinPolicy that refers to a key via the keyed hence the PinPolicy
     element can be embedded in the Key object. Philip to draft new proposal
     email to list.<p></p></span></li>
 <li class="MsoNormal"><span lang="EN-GB">Discussed Magnus&rsquo;s
     email about use of xmlemc: Salah is worried that now a document would be 3
     levels deep: DSKPP-&gt;PSKC-&gt;XMLENC. Is XMLEnc only used for defining
     container keys? Ming has concern about importing the whole XMLEnc schema.
     We need to see an example container document. Also discussed that spec
     would need to have a mandatory modes for interoperability in temrs of
     XMLenc supported encryption methods (PBE, symmetric key etc)<p></p></span></li>
 <li class="MsoNormal"><span lang="EN-GB">Philip asked if
     everyone is happy with URI being attribute or should it be an element. Element
     normally provides more readability Ming will do a check.<p></p></span></li>
 <li class="MsoNormal"><span lang="EN-GB">Philip noted that
     example in 10.1 in spec sent out by Ming has a digest even if
     un-encrypted-&gt; Ming to change. <p></p></span></li>
 <li class="MsoNormal"><span lang="EN-GB">Ming brought up that
     we should indicate more explicitly if a data element is encrypted. Defer
     that until we decided on use of xmlenc for value part. Current thought if
     value does not use xmlenc then we should explicitly mention encryption
     with an optional encrypted=&rdquo;true&rdquo; attribute in the data element.<p></p></span></li>
 <li class="MsoNormal"><span lang="EN-GB">Submission of new
     draft &ndash; Ming to check last submission date. The following is a
     proposal of changes for next submission:<p></p></span></li>
 <ul type="circle">
<li class="MsoNormal"><span lang="EN-GB">URI &ndash; element
      or attribute<p></p></span></li>
  <li class="MsoNormal"><span lang="EN-GB">Corrected example<p></p></span></li>
  <li class="MsoNormal"><span lang="EN-GB">PinPolicy &ndash;
      possibly?<p></p></span></li>
 </ul>
<li class="MsoNormal"><span lang="EN-GB">Authors would like
     to bring xmlenc discussion to IETF meeting so we need examples<p></p></span></li>
 <li class="MsoNormal"><span lang="EN-GB">Need to star
     compiling list of open issues for IETF. (Philip currently unable to attend
     but will assist Ming in creation of slides for IETF meeting)<p></p></span></li>
 <li class="MsoNormal"><span lang="EN-GB">Ming to add missing Time
     based HOTP Data names eg &lsquo;TIME_DRIFT&rsquo;<p></p></span></li>
 <li class="MsoNormal"><span lang="EN-GB">Authors decided that
     more discussions are needed hence another meeting is scheduled for Wed 14th
     of November same time as Monday meeting. Philip to send out meeting maker.<p></p></span></li>
</ul>
<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">________________________________<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Philip Hoyer</span><span lang="EN-GB"> <p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Senior Architect - Office of
CTO<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">ActivIdentity (UK)<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">109
  Borough High Street</span><span lang="EN-GB"><p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">London</span><span lang="EN-GB"> SE1 1NL<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Telephone: +44 (0) 20 7744
6248<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Direct: +44 (0) 20 7744 6455<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Fax: +44 (0) 20 7744 6249<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Private and confidential:
This message and any attachments may contain<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">privileged / confidential
information. If you are not an intended recipient,<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">you must not copy, distribute,
discuss or take any action in reliance on it.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">If you have received this
communication in error, please notify the sender<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">and delete this message
immediately.</span><span lang="EN-GB"><p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

</div>

</div>

[issue32] Define Implementation Requirements for conformance

New submission from Andrea Doherty <adoherty@...>:

Which variant(s) is (are) the MUSTs for the client? for the server?
Same questions pertain to client authentication mechanisms, DSKPP-PRF 
realization(s), encryptiong of the pseudorandom nonces sent from the client.

Also define whether each Appendix is informational or normative.

----------
messages: 75
nosy: andrea, keyprov
priority: critical
status: unread
title: Define Implementation Requirements for conformance

_________________________________________________________
KEYPROV Roundup Issue Tracker <hannes.tschofenig@...>
<http://www.tschofenig.com:8080/keyprov/issue32>
_________________________________________________________

[issue32] Define Implementation Requirements for conformance

Andrea Doherty <adoherty@...> added the comment:

Per comments received from Sean Turner and Hannes, we should specify what are 
MUSTs for conformance to the document, and which Annexes are informational and 
which normative.  As Hannes noted, this will aid in making the document easier 
for implementers to consume.  Here are Sean's specific questions, which I think 
encapsulate all the conformance areas:

1 Which variant(s) is(are) the MUSTs for the client? for the server?  Does
someone claiming conformance to this document need to support 4, 2, and
1-pass or can they claim conformance for just 4, 2, or 1-pass?

2 (sec 4.3.1) Which of the 3 client authentication mechanism is the MUST and
which are the SHOULDs for the client? for the server?

3 (sec 4.5.1) What is the MUST DSKPP-PRF for the client? for the server? The
last sentence points to Annex E for realizations of the DSKPP-PRF but it is
unclear whether the appendix is normative and which realization is required.

4 (sec 4.7) What is the MUST algorithm for encryption of the pseudorandom
Nonces sent from the client?

5 Are Annexes A-E information or normative?  Please indicate as much.

To each point above, here are my comments.  Do you agree?

1. Variants that are MUSTS for the client are 4-pass or 2-pass (not sure if its 
ok to state it this way though), and for the server are 4-pass and 2-pass.
2. The MAC is a MUST, the cert is a MAY.
3. The appendix is normative, and the two realizations therein are MUSTs for 
implementation.
4. The MUST algorithm in sec 4.7 is XOR.  I think it was clear enough.
5. Some Annexes have been moved.  There are only now Appendix A (Integration 
with P11) and B (Example of DSKPP-PRF Realizations).  IMO Appendix A is 
Informative and B is Normative.

----------
assignedto:  -> andrea
status: unread -> chatting

_________________________________________________________
KEYPROV Roundup Issue Tracker <hannes.tschofenig@...>
<http://www.tschofenig.com:8080/keyprov/issue32>
_________________________________________________________

[issue33] Are use cases involving non-authenticated and non-protected transport layer required?

New submission from Andrea Doherty <adoherty@...>:

Should DSKPP support the following use cases:
1. Non-protected Transport Layer (Sec 3.9 of Oct 29, 2007 I-D)
2. Non-authenticated Transport Layer (Sec 3.10 of Oct 29, 2007 I-D)
Assuming a secure transport layer removed complexity from the document.

----------
assignedto: andrea
messages: 78
nosy: andrea, keyprov
priority: wish
status: unread
title: Are use cases involving non-authenticated and non-protected transport layer required?

_________________________________________________________
KEYPROV Roundup Issue Tracker <hannes.tschofenig@...>
<http://www.tschofenig.com:8080/keyprov/issue33>
_________________________________________________________

[issue10] Do we need to provide SOAP binding and where if so?

Andrea Doherty <adoherty@...> added the comment:

The question of expressing DSKPP using WSDL 2.0, and thereby including SOAP 
binding in the core DSKPP document, was raised with the Apps AD. Hannes 
summarized their comment, which was based on RFC 3205 (BCP 56) as follows:

WSDL Usage: Lisa and Chris do not see WSDL as something being 
useful. In fact, I haven't found a person who argued in favor of WSDL. 
Hence, I believe we should avoid it.

While the value of WSDL usage is controversial, e.g., BCP 56 is probably out-of-
date, the decision is to continue expressing DSKPP using XML, and keep the SOAP 
binding description in a separate document (see draft-doherty-keyprov-ct-kip-ws-
00).

----------
status: chatting -> done-cbb

_________________________________________________________
KEYPROV Roundup Issue Tracker <hannes.tschofenig@...>
<http://www.tschofenig.com:8080/keyprov/issue10>
_________________________________________________________