4) how to find a public key certificate matching the ID in the signature and how to check that the private key is asserted to be in the possession of the person controlling [email protected] you are *not* using assertions how would this be accomplished?
Regards Martin ______________________________________________ > From: [email protected] > To: [email protected] > Subject: RE: Code signing and WOT for releases > Date: Wed, 27 Jul 2016 10:01:59 -0700 > > > > -----Original Message----- > > From: Martin Gainty [mailto:[email protected]] > > Sent: Wednesday, July 27, 2016 08:06 > > To: [email protected] > > Subject: RE: Code signing and WOT for releases > > > > > > > > > From: [email protected] > > > To: [email protected] > > > Subject: RE: Code signing and WOT for releases > > > Date: Tue, 26 Jul 2016 10:33:13 -0700 > > > [ ... ] Yesterday, I received an email from one of the users who > > received a security advisory message that I signed. The user's mail > > reader reported that the signature was untrusted (no surprise) and that > > the signature was BAD. Since the mail reader shows the stripped > > message, and it looks perfectly fine, there is no way to help analyze > > that from my end. > > > > > > What I did do was (1) verify the message that was sent to me from the > > list and (2) verify the message in the list archive. I then (3) advised > > the recipient what I did and also (4) how to find a public key > > certificate matching the ID in the signature and how to check that the > > private key is asserted to be in the possession of the person > > controlling [email protected] and how the individual having control of > > that email address is associated with the ASF. > > > > MG>can we assume the key was converted to PKCS8 before asserting the > > key? > > http://stackoverflow.com/questions/5230942/how-to-read-a-private-key- > > for-use-with-opensaml > > > > MG>and then built new SignatureBuilder().buildObject() Signature with > > key locations before assigning > > assertion.setSignature(___)?http://www.programcreek.com/java-api- > > examples/index.php?api=org.opensaml.xml.signature.Signature > > > > MG>/thanks dennis/ > [orcmid] > > This signing had nothing to do with MIME-signatures or SSL. It is a > plaintext message that has a "clearsign" OpenPGP signed section in-line in > the message body. (The signed part was created first and then pasted into > the plaintext email.) You can see the archived form at > <http://mail-archives.apache.org/mod_mbox/openoffice-announce/201607.mbox/browser> > where it is the only message there. At the bottom of the HTML-formatted > display of the message, select the "Unnamed text/plain" link to see a cleaner > plaintext. > > This is not unlike the .asc files that can be made as external PGP signatures > of code, except it is inline instead of external to the file being signed. > > > > > > > (I made another check of the archived message too. The raw form of > > the message fails to verify when downloaded and that appears to be on > > account of some encoding features that have to be processed properly for > > the original text to be reconstituted properly. That might or might not > > be relevant to how that recipient's email reader handles PGP > > > signatures.) > [orcmid] > > (If you look at the raw version on the archive, you will see a pile of =20 > line endings that make the raw form unverifiable. And because the signature > block has a line ending in =, there is an appended raw "3D" that breaks the > whole thing. A client that does not restore the plaintext before checking the > signature will claim that the signature is "BAD".) > > PS: I sent the same message to a colleague who has a PGP-aware email client, > and the message verified automatically and was presented without the > boundaries and the signature block. Instead, there was a marker that > indicated the part of the message that was signed. So it would appear that > the person who reported to me encountered an interoperability failure. > > > > [ ... ] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
