https://bugs.freedesktop.org/show_bug.cgi?id=70183
--- Comment #5 from Mike Kaganski <[email protected]> --- (In reply to Peter Maunder from comment #4) > Is this a PDF password restriction? PDF spec (http://www.adobe.com/devnet/pdf/pdf_reference.html) does not impose any restriction on the password string. It references RFC 2898 (https://www.ietf.org/rfc/rfc2898.txt), which itself specifies: > Throughout this document, a password is considered to be an octet > string of arbitrary length whose interpretation as a text string is > unspecified. In the interest of interoperability, however, it is > recommended that applications follow some common text encoding rules. > ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of > UTF-8.) So, there seems to be no special reason not to use internationalized characters in passwords. Taking into account that PDF standard provides for 32-byte passwords only, using non-ASCII (multi-byte) may somewhat weaken the security, but this should be up to user (probably with warning). However, there must be some convention somewhere regarding this, so that different PDF readers could encode passwords coherently. I haven't found this convention yet. Still, even if there is ASCII-only password restriction, there should be (1) notice in the password dialog (so that user would not enter some characters looking at the keyboard, not at screen, and the absent characters would be unnoticed), and (2) coherent behaviour of both "enter password" and "confirm password" input boxes. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
