# Identity problems with public key **URL:** \ **Category:** Technical\ **Created:** [June 29, 2017, 4:15pm UTC](https://community.blockcerts.org/t/identity-problems-with-public-key/194 "2017-06-29T16:15:21Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Rujia](https://sea2.discourse-cdn.com/flex016/user_avatar/community.blockcerts.org/rujia/32/66_2.png) [@Rujia](https://community.blockcerts.org/u/Rujia)\ **Post date:** [June 29, 2017, 4:15pm UTC](https://community.blockcerts.org/t/identity-problems-with-public-key/194/1 "2017-06-29T16:15:21Z")
Can anyone give me more details of the identity problems? We use public key and address as an Identity symbol. How to proof the public key belongs to whom. traditionally, identity is based on PKIs, how to deal with this problem in our project. ---
**Author:** ![joaosantos](https://avatars.discourse-cdn.com/v4/letter/j/f6c823/32.png) [@joaosantos](https://community.blockcerts.org/u/joaosantos)\ **Post date:** [July 3, 2017, 6:41pm UTC](https://community.blockcerts.org/t/identity-problems-with-public-key/194/2 "2017-07-03T18:41:17Z")
Hello, @Rujia, My name is João, I’m a computer science student and am working on Blockcerts for my MSc thesis. @kim can provide you with a much more comprehensive answer, but in short: Blockcerts does not really take care of identity. The current mechanism relies on issuers to maintain a list of their pub keys (period in which each key was being used) and has a lot of undesirable properties. Going forward I believe that an Identity system will be used, probably something related do distributed identity (DIDs). If you want to learn more about DIDs, the[Rebooting the Web of Trust github repository](https://github.com/WebOfTrustInfo) has a lot of material. [You can start with this post,](https://github.com/WebOfTrustInfo/btcr-hackathon) by Christopher Allen and @kim, which also contains references for other useful documents. You can also take a look at [Christopher Allen’s twitter feed,](https://twitter.com/ChristopherA) it has a lot of useful info. Cheers 🙂 ---
**Author:** ![Rujia](https://sea2.discourse-cdn.com/flex016/user_avatar/community.blockcerts.org/rujia/32/66_2.png) [@Rujia](https://community.blockcerts.org/u/Rujia)\ **Post date:** [July 3, 2017, 10:27pm UTC](https://community.blockcerts.org/t/identity-problems-with-public-key/194/3 "2017-07-03T22:27:05Z")
Hello, João @joaosantos, it is so nice of you. I really appreciate the useful information you provide. The same to you, I’m also a computer science student and am working on Blockcerts for MSc thesis, I hope we can be good friends 😁 More specifically about my topic, I am trying to solve the public key security problems in the Blockcerts project. > “signature”: “IBCnkWta8tgY4Bq43nvPIserPpJx1oMyTN3BKejFVKpVQZyiFLJy4QFOzNFI=”, > “type”: “CertificateDocument”, > “verify”: { > “attribute-signed”: “uid”, > “signer”: “[http://www.blockcerts.org/mockissuer/keys/got\_public\_key.asc](http://www.blockcerts.org/mockissuer/keys/got_public_key.asc)”, > “type”: “ECDSA(secp256k1)” > } As it is shown in the above, We use the ECDSA to ensure the certificate authenticity. Image a situation that the signer’s private key is compromised, anyone who owns the private key can issue the “genuine” certificate arbitrarily. Even the issuer found and changed the private key immediately, It is useful for future certificates but the not previous certificate signed by the old private key, my current solution is as follow. > 1. the issuer published its PGP fingerprint and timestamp(fixed format data) to the public board (their official website, IPFS, other distribute medium), the verification client needs to check the public key(fingerprint) and timestamp first for verifying public key availability. Even the ECDSA private key is compromised in the future, the previous certificate still works due to the transparent expiration date. > 1. when checking the authenticity of the certificate, two factors were considered: the ECDSA scheme(Proof the issuer’s public key corresponding to the signature reasonable) and the transaction address authenticity (Proof the transaction was indeed broadcast by the issuer). Since the address private key and ECDSA scheme private key is totally different, the attacker is harder to forge the certificate. Maybe the solution is naive and inaccurate. Since I am a novice learner in trust and identity field, I sincerely hope you two @kim @joaosantos or other people can give me some advice. ---
**Author:** ![joaosantos](https://avatars.discourse-cdn.com/v4/letter/j/f6c823/32.png) [@joaosantos](https://community.blockcerts.org/u/joaosantos)\ **Post date:** [July 5, 2017, 12:53am UTC](https://community.blockcerts.org/t/identity-problems-with-public-key/194/4 "2017-07-05T00:53:09Z")
Hey, I didn’t quite understand what you meant by: > [@Rujia](#): > > transaction address authenticity (Proof the transaction was indeed broadcast by the issuer). Could you please clarify? (I did not have the opportunity to read your paper yet) I believe that at this point, Blockcerts already offers the functionality you mentioned in 1) > [@Rujia](#): > > 1. the issuer published its PGP fingerprint and timestamp(fixed format data) to the public board (their official website, IPFS, other distribute medium), the verification client needs to check the public key(fingerprint) and timestamp first for verifying public key availability. Even the ECDSA private key is compromised in the future, the previous certificate still works due to the transparent expiration date. and that the problem lies on how that list is maintained. For instance: Now the list of keys (current and past) is maintained by the issuer. So even though when a key ceases to be valid it can still be used to verify past certificates (that were signed with that key), **if the issuer ceases to exist** that list becomes irretrievable so the certificates issued by that issuer can no longer be verified. Another, more subtle, security issue is that issuing and maintaining key pairs is not a trivial task and can be a demanding task for Issuers with little technical background. ---
**Author:** ![Rujia](https://sea2.discourse-cdn.com/flex016/user_avatar/community.blockcerts.org/rujia/32/66_2.png) [@Rujia](https://community.blockcerts.org/u/Rujia)\ **Post date:** [July 5, 2017, 7:53am UTC](https://community.blockcerts.org/t/identity-problems-with-public-key/194/5 "2017-07-05T07:53:42Z")
Hello, João, @joaosantos “transaction address authenticity” means that the issuer may use the same input address to broadcast the transaction, then we can bind this input address together with users’ Identity. I read the up-to-date guide document yesterday and found that the blockcerts had been updated to Version 2.0, which is totally different Version 1.2, In the version 1.2 the blockcerts only use ECDSA to ensure the certificate authenticity, which is shown as follow: > **[Blockchain Certificates](http://web.archive.org/web/20161101115608/http://www.blockcerts.org:80/guide/verification-process.html)** > > Build apps that create, issue, view, and verify blockchain-based certificates within academic credentialing, professional certifications, and workforce development. 5. Check that the certificate was authored by the issuer. > To check that the certificate was authored by the issuer, verify that the signature in the \>local certificate file was signed with the issuer’s key. > The public key from the sample certificate can be found \>at [http://www.blockcerts.org/mockissuer/issuer/got\_public\_key\_live.asc](http://www.blockcerts.org/mockissuer/issuer/got_public_key_live.asc) under the ‘\> \>issuerKeys’ field. This needs to be copy/pasted into the code. My solution is based on the version 1.2, I am sorry for my information lag. and congratulation the blockcerts have implemented this functionality @kim . ---
**Author:** ![kim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.blockcerts.org/kim/32/307_2.png) [@kim](https://community.blockcerts.org/u/kim)\ **Post date:** [July 9, 2017, 10:06pm UTC](https://community.blockcerts.org/t/identity-problems-with-public-key/194/6 "2017-07-09T22:06:56Z")
Thanks Rujia! Yes, our [blockcerts.org](http://blockcerts.org) site is now current as of 2.0. In addition, some of the more technical docs have been moved to their github repos (to reduce duplication). Sorry for the delay! - Kim