Network Working Group                               N. Mavrogiannopoulos
Internet-Draft                                                   Red Hat
Updates: 7292,8018 (if approved)                            D. Woodhouse
Intended status: Informational                       Amazon Web Services
Expires: November 8, 2018                                    May 7, 2018

Internationalized passwords in Password-Based Cryptography Specification


   This memo clarifies the requirements of using internationalized
   strings as passwords in Password-Based Cryptography Specification
   version 2.1 [RFC8018] (PKCS#5) and Personal Information Exchange
   Syntax [RFC7292] (PKCS#12).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   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."

   This Internet-Draft will expire on November 8, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Mavrogiannopoulos & WoodExpires November 8, 2018                [Page 1]

Internet-Draft    Internationalized passwords in PKCS#5         May 2018

1.  Introduction

   Utilizing Internationalized passwords is not known to lead to a
   consistent user experience.  US-ASCII passwords as usually preferred
   since they are unambiguously interpreted by applications, even though
   UTF-8 [RFC3629] updates US-ASCII in a backwards compatible way.

   The reason for preferring US-ASCII passwords, is the fact that UTF-8
   does not imply that strings conforming to it, are unambiguously
   unique.  There are can be various forms of the same string which may
   look identical to an observer, even though it is being represented by
   a different byte string.  The following are certain issues with using
   passwords in UTF-8.

   o  There exist various normalization forms, which result to different
      data for the same input.

   o  There is no consistent input form in diverse systems.

   o  There are various deprecated alphabets which should not be allowed
      for future compatibility.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Passwords in PKCS#5

   The existing PKCS#5 [RFC8018] methods (PBES1, PBES2, PBMAC1) treat
   passwords as an opaque string and describe the usage of ASCII and
   UTF-8 strings as a possibility of encoding them.  In the interest of
   interoperability, applications conforming to this specification
   should encode passwords in UTF-8 NFC form and SHOULD be adhering to
   the OpaqueString profile (section 4.2 of [RFC7613]).

   Note that the OpaqueString profile does not allow empty passwords.
   Since these passwords are often used in practice, applications
   conforming to this document MAY allow empty (zero-length) passwords,
   when they are not they result of the [RFC7613] processing.  That is,
   an empty string generated from any non-empty internationalized input
   MUST NOT be used.

Mavrogiannopoulos & WoodExpires November 8, 2018                [Page 2]

Internet-Draft    Internationalized passwords in PKCS#5         May 2018

4.  Passwords in PKCS#12

   The PKCS#12 document [RFC7292] defines the use of BMPString passwords
   (a subset of UTF-16), for its defined encryption methods.  This
   document does not add any further restrictions to the input passwords
   of these methods, however it is RECOMMENDED to use (big-endian)
   UTF-16 NFC form [NFC] when encoding the password.

   Furthermore, when the PKCS#12 container files are combined with
   methods from PKCS#5 [RFC8018], e.g., AES-CBC-Pad, the passwords
   SHOULD be adhering to the recommendations in Section 3.  In that
   case, since typically the passwords of the MacData field and the
   encrypted data match, applications which restricted the MacData
   password to BMPString set, SHOULD fail when the input password cannot
   be expressed in that set.

5.  Compatibility notes

   Note that software wishing to decrypt files with internationalized
   passwords MAY prepare to handle password encoding methods not
   adhering to this document.  The following paragraphs document
   existing practices and known bugs in popular software.

5.1.  Attempting the password in NFC

   The recommendations in the PKCS#5 document are not sufficient to
   deduce the UTF-8 input form of internationalized passwords.
   Implementations receiving an internationalized password may attempt
   decrypting using the password in UTF-8 NFC form.

5.2.  OpenSSL's incorrect password conversion

   OpenSSL versions prior to 1.1.0 had a bug which always assumed the
   input password was in the ISO8859-1 character set regardless of the
   actual character set used on the system.  This occurred because it
   attempted to convert to UTF-16 for the BMPString merely by
   alternating each byte from the input string with a zero byte to
   expand to 16 bits.

   As an example, consider a PKCS#12 file for which the password is
   intended to be the following two characters:



   For the purpose of this example, the user is operating in a legacy
   8-bit locale using the ISO8859-2 character set.  The above two

Mavrogiannopoulos & WoodExpires November 8, 2018                [Page 3]

Internet-Draft    Internationalized passwords in PKCS#5         May 2018

   characters are thus provided to the application as the bytes 0xC3

   The correct form of that password for PKCS#12 key derivation includes
   precisely those characters in UTF-16 big-endian form as required for
   a BMPString: the bytes 0x01 0x02 0x01 0x7B 0x00 0x00.  This is the
   correct version which any application supporting the use of files for
   certificates and keys MUST support.

   Historical versions of OpenSSL, as noted, would assume that the input
   bytes were in the ISO8859-1 character set.  So the input bytes 0xC3
   0xAF would therefore be interpreted as the two characters:


      U+00AF MACRON

   The BMPString used for key derivation in this case would include the
   bytes 0x00 0xC3 0x00 0xAF 0x00 0x00.

   An application in a non-ISO8859-1 locale can therefore attempt to
   decrypt such wrongly-created files by treating the input password as
   if it is a sequence of bytes in ISO8859-1 rather than the locale
   character set in which it really was provided.  The application can
   generate the BMPString by converting from ISO8859-1 to big-endian
   UTF-16, and attempt to decrypt the file by deriving the key using
   that rendition of the password.

6.  Security Considerations

   All the considerations in [RFC8018] and [RFC7292] apply.

7.  IANA Considerations


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-

Mavrogiannopoulos & WoodExpires November 8, 2018                [Page 4]

Internet-Draft    Internationalized passwords in PKCS#5         May 2018

   [RFC7613]  Saint-Andre, P. and A. Melnikov, "Preparation,
              Enforcement, and Comparison of Internationalized Strings
              Representing Usernames and Passwords", RFC 7613,
              DOI 10.17487/RFC7613, August 2015, <https://www.rfc-

   [RFC8018]  Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
              Password-Based Cryptography Specification Version 2.1",
              RFC 8018, DOI 10.17487/RFC8018, January 2017,

   [RFC7292]  Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
              and M. Scott, "PKCS #12: Personal Information Exchange
              Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,

   [NFC]      Davis, M. and M. Duerst, "Unicode Standard Annex #15:
              Unicode Normalization Forms r.44", Unicode , February

8.2.  Informative References

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <>.

Appendix A.  Acknowledgements

   The authors would like to thank Russ Housley for his comments on this

Authors' Addresses

   Nikos Mavrogiannopoulos
   Red Hat, Inc.
   Czech Republic


   David Woodhouse
   Amazon Web Services


Mavrogiannopoulos & WoodExpires November 8, 2018                [Page 5]