W3C home > Mailing lists > Public > xml-encryption@w3.org > June 2002

Re: Supplemental list of Password-Based Encryption Algorithms

From: Tom Gindin <tgindin@us.ibm.com>
Date: Wed, 26 Jun 2002 12:03:09 -0400
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org, dee3@torque.pothole.com, reagle@w3.org
Message-ID: <OF5B33A3EC.6C2F3749-ON85256BE4.0055EE0F@pok.ibm.com>


      Merlin:

      Thanks for your response.  The current draft does list all the
algorithm URI's with names which come from a signature base, as all but one
of them are signature algorithms.  In fact, the one encyrption algorithm in
the draft has an apparent typo in its name.  I did suggest an alternate
name form, ending with something like "xmldsig-more#PBEP12SHA_3KeyDES_CBC".
I think that putting a signature indication in the algorithm name of an
encryption algorithm is an odd thing to do if it's nearly as easy to assign
a second URI root which reflects the fact that these are encryption
algorithms rather than signature ones.  If it is necessary to have only one
root per document, then the form including xmldsig-more should be used, of
course.
      I have no intention of adding all the known algorithms to this draft,
as there are about 20.  I'm not particularly worried about RC2 one way or
the other, but the issue of PKCS#5 is worth more of a look.  PKCS#12 is
simpler to handle in several ways.  However, PKCS#5 version 2 (as opposed
to 1.5) does suggest that Unicode be encoded as UTF-8, so it's also
somewhat Unicode aware.  Unlike PKCS#12, the presence or absence of a null
terminator is not dictated by the standard so there's some possibility of
interoperability issues there.  I do have direct knowledge of the contents
of a couple of crypto libraries, one of which supports PKCS#5 without
PKCS#12 while it also supports all required signature algorithms although
not OAEP or AES.  Does anyone have a crypto library which supports OAEP,
AES, and PKCS#5 without supporting PKCS#12?  If there aren't any, dropping
PKCS#5 in favor of PKCS#12 becomes much more reasonable.
      I have no objection to adding the salt parameter to PKCS#12
algorithms, although it should default to a binary string of zero length.

            Tom Gindin


merlin <merlin@baltimore.ie>@w3.org on 06/26/2002 09:26:10 AM

Sent by:    xml-encryption-request@w3.org


To:    Tom Gindin/Watson/IBM@IBMUS
cc:    xml-encryption@w3.org, dee3@torque.pothole.com, reagle@w3.org
Subject:    Re: Supplemental list of Password-Based Encryption Algorithms




Hi Tom,

Some quick comments:

Names such as ...xmldsig-more#pbes2-tripledes-cbc,
#pbe-sha1-tripledes-cbc (or whatever) would be more in line
with our other algorithm URIs. The text would then define their
correspondence with PKCS#12 pbeWithSHAAnd3-KeyTripleDes-CBC,
etc.

The namespace for any defined elements would probably be
just ...xmldsig-more#.

What would your opinion be of simply defining algorithms from
PKCS#12, which are Unicode-aware, and dropping RC2 unless it
is adopted as a standard cipher algorithm in xmldsig-more#? If
the intention is that we can encapsulate legacy ciphertext,
then I would assume we'd need to support all the algorithms,
which would seem troublesome.

  #pbe-sha1-arcfour = PKCS#12 pbeWithSHAAnd<n>BitRC4
? #pbe-sha1-rc2-cbc = PKCS#12 pbeWithSHAAnd<n>BitRC2-CBC
  #pbe-sha1-tripledes-cbc = PKCS#12 pbeWithSHAAnd3-KeyTripleDES-CBC

REQUIRED parameters, in this order:

  ( <KeySize>number</KeySize> - for arcfour, rc2 )
  <Salt>base64</Salt>
  <Iterations>number</Iterations>

Thanks for putting this together,

Merlin

r/tgindin@us.ibm.com/2002.06.26/08:03:42
>
>
>      The following is my suggestion for a new subsection of
>draft-eastlake-xmldsig-uri.  It is in RTF format ((See attached file:
>URISec.rtf)), but the ASCII text is attached at the bottom of this note.
>Several features of the draft may need further work or may need to be
>changed.  First, there is some question as to the URI space from which the
>identifiers should be assigned.  I have provisionally defined a new
>subspace which is specific to this use - "2002/06/xmlenc-pbe#".  If it is
>felt that the URI's need to match those in the rest of this draft, which
>are mainly for signatures, that string can be changed to
>"2001/04/xmldsig-more#PBE" wherever it appears in this section.  Second, I
>don't know how to define the name space under which the proposed
>"InitVector" element will be defined, and I would appreciate someone
>correcting its definition.  Here's the RTF format:
>      On a minor issue somewhat related to this draft, the identifier for
>the ARCFOUR encryption algorithm seems to have a typo in it, with
>"xmldsgi-more" in place of "xmldsig-more".  Can this be corrected?
>
>            Tom Gindin
>
>2.7   Password-Based Encryption Algorithms
>
>2.7.1 PKCS#5-based password-based encryption algorithms
>
>      The algorithms specified in this section derive keys (and IV's for
>      block ciphers) for their symmetric algorithms using the PBES2 scheme
>      specified in section 6.2 of PKCS#5[a] with the PBKDF2 key derivation
>      technique specified in section A.2 of PKCS#5[a].  Part of their name
>      contains the symmetric encryption algorithm used.  Each of the
>      algorithms specified in this section requires a single parameter,
>      containing the value of the initialization vector, which should be
>      specified using a newly defined element subordinate to
>      EncryptionMethodType, to be known as "InitVector", whose type is
>      base64Binary.  For variable key length algorithms such as RC2, the
>      KeySize element must be used to specify the length of the key.
>   Identifiers:
>       http://www.w3.org/2002/06/xmlenc-pbe#P5DESEDE3_CBC
>       http://www.w3.org/2002/06/xmlenc-pbe#P5RC2_CBC
>
>   An example of use is
>
><EncryptionMethod
>              Algorithm
>="http://www.w3.org/2002/06/xmlenc-pbe#P5DESEDE3_CBC">
><??:InitVector">ABCDEFGHIJK="</??:InitVector>
></EncryptionMethod>
>
>
>2.7.2 PKCS#12-based password-based encryption algorithms
>
>      The algorithms specified in this section derive keys (and IV's for
>      block ciphers) for their symmetric algorithms using the techniques
>      specified in section B of PKCS#12 [b].  Part of their name contains
>      the symmetric encryption algorithm used. For variable key length
>      algorithms such as RC2 or RC4, the KeySize element must be used to
>      specify the length of the key.
>
>Identifiers:
>       http://www.w3.org/2002/06/xmlenc-pbe#P12SHA_3KeyDES_CBC
>       http://www.w3.org/2002/06/xmlenc-pbe#P12SHA_RC2_CBC
>       http://www.w3.org/2002/06/xmlenc-pbe#P12SHA_RC4_CBC
>
>
>      References:
>
>
>      [a] RSA Laboratories, PKCS #5 v2.0: Password-Based Cryptography
>      Standard, Mar. 1999.
>      [b] RSA Laboratories, PKCS #12 v1.0: Personal Information Exchange
>      Syntax, Jun. 1999.
>
>
Received on Wednesday, 26 June 2002 12:03:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:04 UTC