[Python-checkins] peps: PEP 427: remove signing algorithms

[daniel.holth]

http://hg.python.org/peps/rev/e238af91e1bc
changeset:   4586:e238af91e1bc
user:        Daniel Holth <dholth at fastmail.fm>
date:        Tue Nov 13 11:31:37 2012 -0500
summary:
  PEP 427: remove signing algorithms

files:
  pep-0427.txt |  89 ++++++++-------------------------------
  1 files changed, 20 insertions(+), 69 deletions(-)


diff --git a/pep-0427.txt b/pep-0427.txt
--- a/pep-0427.txt
+++ b/pep-0427.txt
@@ -243,57 +243,24 @@
     file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT\_pNh2yI,3144
     distribution-1.0.dist-info/RECORD,,
 
-RECORD.jws is not mentioned in RECORD at all.  Every other file in the
-archive must have a correct hash in RECORD, or the installation will
-fail.
+The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in
+RECORD at all since they can only be added after RECORD is generated.
+Every other file in the archive must have a correct hash in RECORD,
+or the installation will fail.
 
-The signature format is derived from the JSON Web Signatures (JWS)
-specification.  One or more JSON Web Signature JSON Serialization (JWS-JS)
-signatures may be stored in a file RECORD.jws adjacent to RECORD.
-
-A signature-aware installer could be instructed to check for a
-particular Ed25519 public key by using an extended "extras" syntax.::
-
-    # request a normal optional feature "extra", and indicate
-    # the package should be signed by a particular 
-    # urlsafe-b64encode-nopad encoded ed25519 public key:
-    package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
-
-An application could distribute a requires.txt file with many such lines
-for all its dependencies and their public keys.  By installing from this
-file an application's users can know they are getting packages from the
-same publishers.
-
-Applications that wish to "fail open" for backwards compatibility with
-non-signature-aware installers should specify that their package
-provides the extra ``ed25519=(key)`` with no associated dependencies.
-
-
-JSON Web Signatures Extensions
-''''''''''''''''''''''''''''''
-
-The Ed25519 algorithm is used as an extension to the JSON Web Signatures
-specification.  Wheel uses ``alg="Ed25519"`` in the header.  The key
-attribute holds the signature's public JSON Web Key.  In JSON Web Key
-/ JSON Private Key the Ed25519 verifying (public) key is called vk and
-the signing (private) key is called sk.
-
-Example header::
-
-    {
-      "alg": "Ed25519",
-      "jwk": {
-        "alg": "Ed25519",
-        "vk": "tmAYCrSfj8gtJ10v3VkvW7jOndKmQIYE12hgnFu3cvk"
-      }
-    }
-
-Example payload, always the SHA-256 hash of RECORD::
+If JSON web signatures are used, one or more JSON Web Signature JSON
+Serialization (JWS-JS) signatures may be stored in a file RECORD.jws
+adjacent to RECORD.  JWS is used to sign RECORD by including the SHA-256
+hash of RECORD as the JWS payload::
 
     { "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }
 
-A future version of wheel may include timestamps in the payload or in
-the signature.
+If RECORD.p7s is used, it must contain a PKCS#7 format signature of
+RECORD.
+
+A wheel installer may assume that the signature has already been checked
+against RECORD, and only must verify the hashes in RECORD against the
+extracted file contents.
 
 See
 
@@ -301,7 +268,6 @@
 - http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html
 - http://self-issued.info/docs/draft-ietf-jose-json-web-key.html
 - http://self-issued.info/docs/draft-jones-jose-json-private-key.html
-- http://ed25519.cr.yp.to/
 
 
 Comparison to .egg
@@ -342,27 +308,12 @@
     resource)`` even though *those* files will usually not be distributed
     in *wheel's* ``.data`` directory.
 
-Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA?
-    Wheel's signing scheme is designed to protect against cryptography
-    that is not used.  The system yields a tiny, performant pure-Python
-    implementation that can just be included with the reference installer.
-    The 32-byte public keys are convienent to share directly in the
-    same way you would share a SHA-256 digest.  Since the signatures
-    are inside the archive itself, they are more likely to be present
-    at install time compared to detached signatures.
-
-    Wheel's signing system is designed to be used more like an md5 sum
-    or a secure hash used to verify the integrity of an archive than
-    something like PGP or X.509 signatures.  A secure hash can verify
-    the integrity of a single archive, but a wheel signing key verifies
-    the signer of all packages signed with that key.  Once you know to
-    expect a particular signing key, a signature-verifying installer
-    protects you from installing anything but intact packages from the
-    expected signers.  It makes no difference whether the wrong packages
-    come from choosing the wrong package index, disk corruption, or an
-    actual attack; if a package is not signed with the expected key,
-    with its file contents matching their hashes in RECORD, then it will
-    not be installed.
+Why does wheel include attached signatures?
+    Attached signatures are more convenient than detached signatures
+    because they travel with the archive.  Since only the individual files
+    are signed, the archive can be recompressed without invalidating
+    the signature, or individual files can be verified without having
+    to download the whole archive.
 
 Appendix
 ========

-- 
Repository URL: http://hg.python.org/peps