RFC 4880 uses the term "creation time" to refer to when keys and
signatures are created, and this is partially followed already. This
CL applies it to the rest of places that were using "currentTime"
instead.
Change-Id: I8a83604b53a240689327defd89e22ddbebe3b679
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/175446
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Rather than using the first subkey binding signature encountered, use
the one with the most recent creation data, as per the recommendation from
RFC 4880:
> An implementation that encounters multiple self-signatures on the
> same object may resolve the ambiguity in any way it sees fit, but it
> is RECOMMENDED that priority be given to the most recent self-
> signature.
This allows subkeys to approach expiry then be re-signed with a new expiry.
This extends the recent commit 0e37d00 by @aviau and @FiloSottile.
Fixesgolang/go#26468
Change-Id: I7f12706727373259c188bfee4254306ef9d4e935
GitHub-Last-Rev: 0da814166411a3c3334312576d3f7f8f2bba4ff4
GitHub-Pull-Request: golang/crypto#57
Reviewed-on: https://go-review.googlesource.com/135357
Reviewed-by: Filippo Valsorda <filippo@golang.org>
In change id Id992676ef2363779a7028f4799180efb027fcf47, "current" was
moved into the UserID packet handling scope. This was the only thing
preventing us to move the UserID packet handling code inside its own
function.
This patch moves the UserID packet handling code inside a new addUserID
function. This is consistent with the other existing addSubKey method.
"current" is renamed to "identity" for improved readability.
Change-Id: I5d58eb35ab5fa9fc7d9d111fa186fec6f5e11e79
Reviewed-on: https://go-review.googlesource.com/118959
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Consider the following packet ordering scenario:
PUBKEY UID SELFSIG SUBKEY REV SELFSIG
In this scenario, addSubkey would only consume the REV signature after
the subkey, leaving SELFSIG to be read by ReadEntity, which in turn
would add the last SELFSIG to the UID's signatures, which is wrong to do
because this is a SUBKEY SELFSIG, not a UID signature.
Remove "current" from the ReadEntity scope, it should only be visible
to the UserId packet handling code.
Keep the warning about signature packets found before user id packets.
Without it, I would not have found this bug.
Modify addSubKey so that it consumes all signatures following the SUBKEY
packet, keeping eithier the first valid signature (like we did before)
or any valid revocation.
In a follow-up patch, we can improve this further by keeping the
most recent signature, as suggested by RFC4880:
> An implementation that encounters multiple self-signatures on the
> same object may resolve the ambiguity in any way it sees fit, but it
> is RECOMMENDED that priority be given to the most recent self-
> signature.
Fixesgolang/go#26449
Change-Id: Id992676ef2363779a7028f4799180efb027fcf47
Reviewed-on: https://go-review.googlesource.com/118957
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Signing was moved in NewEntity as it makes more sense there, but there
might be code that relies on SerializePrivate to make signatures with
parameters that were modified after NewEntity.
As it used to always sign in SerializePrivate, it shouldn't break
anything to sign in both places.
Fixesgolang/go#25463
Change-Id: Ia7f509daf31ac05fedc441225d554f333b288d70
Reviewed-on: https://go-review.googlesource.com/118015
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Yaron de Leeuw <jarondl@google.com>
Reviewed-by: Alexandre Viau <viau.alexandre@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The existing code was wrongly assuming that UserID packets must be
immediately followed by a Signature packet. However, this is not true.
See RFC4880 11.1:
> Immediately following each User ID packet, there are zero or more
> Signature packets.
This change will ensure that Entities that are not immediately followed
by a Signature packet are read without raising a StructuralError.
Instead, UserID packets that are not immediately followed by a self
signature will be ignored.
Maximum backwards compatibility is retained because revoked UserIDs are
not added to the Entity's identities.
In a follow-up patch, we should probably add these UserIDs to the
Entity's identities too, but not without making sure that the revocation
is also available in the Entity's (or the Identity's) Revocations slice.
This would require adding support for a new Signature Type,
"Certification revocation signature", as defined in RFC 48880 5.2.1.
Fixesgolang/go#25850
Change-Id: Idde34b97429998f28e0c687171024e51ed959bf0
Reviewed-on: https://go-review.googlesource.com/118376
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously if you created a new Entity then ran `Serialize` _before_ running `SerializePrivate`, the resulting armored public key was corrupted, giving the error of `unexpected EOF`. This fix signs the public key with the private key upon creation of a NewEntity. Since SerializePrivate only is applicable to entities created with NewEntity per the docs we can also safely remove the signing portion from that function.
Fixes#25463
Change-Id: I58b808987ee173079f33bce3d6c3527f9233b2cd
GitHub-Last-Rev: 2c4b8e4d630a06d782816f8fbd3d59f01ece2565
GitHub-Pull-Request: golang/crypto#47
Reviewed-on: https://go-review.googlesource.com/114001
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The openpgp package promotes bad defaults by not setting the
preferred cipher and hash of new entities created by
`openpgp.NewEntity`.
The preferred hash can be set by passing a `packet.Config`
with a `DefaultHash` set, but the same cannot be done for
the preferred cipher.
This change copies the DefaultCipher into the self-signature, similar to
DefaultHash.
Change-Id: I80e1289d67b7cd4079be8c1d5ba603a555dbe5c1
Reviewed-on: https://go-review.googlesource.com/66430
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Confusingly, `Identity.Name` should actually refer to `uid.Id` and not
`uid.Name`. This fixes the code in NewEntity, and creates a test case to
verify.
Change-Id: Id46de876fc7b0359faecfeb9b09a8e454710d485
Reviewed-on: https://go-review.googlesource.com/92595
Reviewed-by: Adam Langley <agl@golang.org>
None are "wrong" per se, but there are a lot of good suggestions and
in one case a docstring that was not present in godoc due to the
presence of an extra newline.
Changed "Id" in struct properties to "ID" in some non-exported
structs. Removed a trailing period from some error messages; I believe
the exact contents of error strings are not covered by the Go
compatibility promise.
Change-Id: I7c620582dc247396f72c52d38c909ccc0ec87b83
Reviewed-on: https://go-review.googlesource.com/80145
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Say the user wants to create a NewEntity, then Serialize the private and public
keys. Then call Encrypt. The Hash used first for Encrypt will be `RIPEMD160`,
which is not compiled in by default. So say they _specifically_ pass
crypto.SHA256 as the Default hash to NewEntity, this should set the
PreferredHash in the SelfSignature so they can be encrypted with that hash.
Related to golang/go#12153
Change-Id: I3d89f9d60f9abb29ec8365f81da38b8cd0594587
Reviewed-on: https://go-review.googlesource.com/23209
Reviewed-by: Adam Langley <agl@golang.org>
Entity.SignIdentity used the wrong signature function and produced invalid
certification signatures. Fixed.
VerifyUserIdSignature was used for checking the self-signature on an identity,
but didn't support anything but a self-signature. This change alters the
low-level API so that checking cross-signatures is possible.
Fixesgolang/go#7371.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/96240043
I ran go vet over all of go.crypto and removed lots of panic("unreachable") that are no longer needed.
R=golang-dev, r, dgryski
CC=golang-dev
https://golang.org/cl/10113043
These are improvements I've made as necessary to develop Hockeypuck,
an OpenPGP keyserver (https://launchpad.net/hockeypuck).
The max armor line length was increased to 96 because some keyservers (SKS)
will output armor with lines greater than 64 (the prior max).
I've exposed packet.ReadEntity to support stream-parsing, useful for
large SKS dump files.
ReadKeyRing attempts to recover in the event of malformed data.
Because many packet types are not yet supported, I added OpaquePacket to
capture unsupported types for offline storage and later reparsing.
R=agl
CC=golang-dev
https://golang.org/cl/6927044
Manual edits to README.
Moved from main Go repository, deleted Makefiles, ran gofix -r go1rename.
Tested with: go test code.google.com/p/go.crypto/...
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5564059
Matthew Dempsky
Paul M Furley
aviau
Filippo Valsorda
Ryan Canty
Damien Tournoud
Yaron de Leeuw
Kevin Burke
Joe Tsai
Jessica Frazelle
Jeff R. Allen
Keith Ball
Andrew Gerrand
Adam Langley
Casey Marshall
Russ Cox