I am trying to get zoopla rtdf connected and have a question about their PEM certification process on their Sandbox.
Once the CSR (generated by user) is uploaded via Zooplas CSR signing page they send you a 12 digit success token response ...which I have.
In the docs they then say they will contact you verbally to verify you are real by asking for your token number as above. All good in theory but how do they contact you when they have not taken or requested a tel number or even an email address. Nor do they now even provide s technical contact number or email. Very Confused!!
Here is their documentation.
https://realtime-listings.webservices.zpg.co.uk/docs/latest/documentation.html
Go to section 3 and you will see the confusion.
When you create the CSR you can insert your email address into the file as you create it. And if I remember correctly the csr submission page will ask you for a contact number. HTH
Related
There're plenty of sites, where you have to sign their 'sign in' message in order to get JWT from them. For example, https://www.cryptokitties.co uses such login system. It verifies the signature on the back-end and sends JWT back if address matches. It works good, but such approach disturbs me in the matter of security.
Assume, that someone has created absolutely identical to cryptokitties fake website. User hasn't noticed that domain is different, signs the same message ("To avoid digital cat burglars, sign below to authenticate with CryptoKitties") and at this point he already provided scammer with his signature and address, as message was the same, therefore it will work on original website. So basically you can loose your account by signing the same message on the completely different site. The saddest part, is that you cannot reset the private key, which means that your account has gone for good.
I'm not an expert, but it seems to me like a huge hole in security.
The solution I'm thinking about, is to encrypt the signature on the client before sending it on the back-end. With such approach, back-end will only send you a JWT if you've signed a message on our front-end. So, firstly back-end decrypts the signature and then verifies the message and address. It will skip signatures which were created on other sites as the decryption will fail.
So far we eliminated fake websites problem. But there is another one: attacker can intercept an already encrypted signature and use it on our site. And once again there is no way to reset the signature, it'll remain the same. So what I came up with is, signature must be disposable, it can be used only once. Before signing a message client requests from the back-end special random number linked with according wallet. Based on this number we build signature message like this: "To avoid digital cat burglars, sign below to authenticate with CryptoKitties #564324". Firstly, back-end decrypts the signature, verifies the address and then checks whether specified random number exists in database. Once login is succeeded, the random number is deleted from the database. Now, even if user looses his signature, it can't be used by attacker, because it's already expired.
What do you think? Does described approach make sense?
You have the right idea with "signature must be disposable". The concept is called a nonce (a value used to protect private communications by preventing replay attacks).
Your following logic is correct as well, except that you don't need to delete the nonce from the database, but rather rotate it. I.e. update the value to a new pseudo-random (or at least hard to guess) value.
So I have a document shared between two or more users. Call them Alice and Bob.
When editing this document, Alice is signed in using OAuth with office 365 or google gsuite; I'll call that an identity provider.
When I pass this document to Bob, I want to be able for Bob to have confidence that the content written by Alice was indeed written by someone with the ability to sign in the identity provider as Alice.
The obvious way to do this is for Alice to digitally sign the changes in the document with a public/private key pair, and then connect the public key to her own identity.
This will require that Bob can get at that public part of the key through a way they can reasonably verify required that Alice put that public key there.
Also, I want the file's current location/storage/transmission to not be required to prove the identity of Alice in any way. And, ideally, I'd like Alice to be able to authenticate, disconnect from the internet, and continue to be able to make provably-authored edits on her document.
I'm afraid I'm reinventing the wheel, but I cannot find any evidence that there are pre-existing APIs for doing this. This seems like a really basic set of operations; being able to sign data with identity, and verify it was that identity that signed it. I was somewhat surprised when I couldn't find an API to do this.
Embedding a link to a shared document that Alice has on her cloud storage, and having Bob go and fetch it to verify the signature, is one thing I'm considering; is there a way to have a stable URL with both of those storage providers that can be traced back to being connected to Alice?
Is there a better approach?
Alice must get document signing certificate separately from the office 365 or gsuite. It is possible to get simple and cheap certificate that shows that this e-mail address control has been verified.
If the private key is on the HSM like Smart Card or USB token then it is possible to get eIDAS approved or Adobe Trusted list CA signed certificate and signature validation is relatively easy.
It is also possible to setup your own CA and in this case you need to implement signature validation as well and make sure your own CA is trusted by Bob
I have a eSigned / Digitally signed PDF, the document is signed using iText lib in detached signature. I am having issue while verifying the signature, getting message "signers identity is invalid because it has expired or not yet valid" and in signer info "There were errors building the path from signers certificate to an issuer certificate."
I have tried many ways to validate the signature but couldn't get any success. If I explicitly add signers certificate as trusted certificate then I get a green check and able to verify the signature but I think thats not the correct way to do it.
Adobe Signature setting are as follow:-
digitally signed pdf can be found heredigitally signed document
can anyone please help to resolve this issue.
I have tried many ways to validate the signature but couldn't get any success.
That is not surprising: Your signature is not valid. In the PDF signature field value there is a signing time 2020/06/11 09:28:35 GMT but your signer certificate is valid not before 2020/06/11 09:29:44 GMT and not after 2020/06/11 09:59:44 GMT. At the claimed signing time, therefore, your signer certificate was not valid yet and could not create a valid signature.
Apparently you sign using a signing service that creates a short-time certificate just in time when your signature request to it arrives. Unfortunately that is after the time iText stored as signing time in the PDF at the beginning of the signing process.
Thus, one way to resolve the issue is to tell iText to use a time slightly (e.g. two minutes) in the future.
You can do that by means of the PdfSignatureAppearance method setSignDate.
Your signature actually also violates a recommendation from the specification: The afore mentioned signing time stored in the signature field value dictionary should be used only when the time of signing is not available in the signature (the embedded signature container). In your case, though, the embedded signature container does contain a signingTime signed attribute with value 11/06/2020 09:29:44 GMT which is not before the start of certificate validity.
As that only is a recommendation, your PDF signature is not made invalid by having two signing time values. But as the values differ, this can result in different verification results by different validators, using either one or the other value.
Thus, another way to resolve the issue is to make sure no signing time value is added to the signature value dictionary at all. This additionally makes your signed PDF follow the recommendation above and so be more precise.
Unfortunately using the PdfSignatureAppearance method setSignDate to set a null value does not work, later on in the signing process this results in NullPointerException occurrence. But if you use a custom ExternalSignatureContainer implementation in your signing code (and not an ExternalSignature implementation), you can remove that entry in your modifySigningDictionary implementation. The key is PdfName.M.
As an aside, as your signing certificate is only valid for half an hour, validators may also reject it if their validation policy only trusts digital time stamps, not unsecured date-time values.
Thus, you should add revocation information and digitally time stamp the whole construct during the life time of the certificate to guarantee long term validation.
I understand what your issue is. There's a whole new way of solving it, in 3 steps.
Open in Adobe Acrobat DC or any Adobe pdf editor software you have.
In Edit, go to Preferences, in the end come to Signatures. Click on verification, more, in verification time section, select current time. Same location, verification information section, select never.
In Windows integration, tick validating signatures and validating certified documents. Click ok.
Close all popups. Come back to signature area and right click to select, validate signature.
Done ✅
I know how signature works, etc. Maybe it's not about pdf but about e-sign, but whatever.
Imagine we have a contract "I give you $100, you give me a cookie" (expensive cookie). Imagine you and me generated private|public keys signed that contract.
Then I gave you $100 but you didn't give me the cookie. I want to go to a сourt, but you removed your private key and tell me that you never signed anything. How court knows that YOU signed that document if anyone can generate sign keys. They are not tight in any way with a signer. Government doesn't have any record like "this public key id a public key of that person ID" to demand from you to give me my cookie. How that works legally? If we both say "yes, we signed" - it's easy, but we can easy say - I don't sign that and nobody can 100% prove that I used that key to sign.
First of all, you do not use self signed certificates, you use certificates issued by a trusted certificate authority (CA). Then when you sign the contract you include long term validation (LTV) data in your signature so that it can be validated even if the certificate has been revoked.
We have Echosign global account. we are trying to support multiple signature in our embbedded widget, but we have the limitation that we don't know email-id of the multiple signer at the time when widget is created. Text-tags maps the signers with the emailid that we have, but we don'thave email id at that point.
Does echosign provide any way to achieve this?
I don't think not knowing signer's email id's will have any issues.
Echosign does associate every signer with an email id, but you need not provide it at the time of creation.
Just have different signers like signer1,signer2, etc. , have different text tags like {{name_es_:signer1}},{{name_es_:signer2}},etc. and whenever they sign, depending on your signature settings echosign will allow them to verify their emailids after signature.
email fields are not mandatory with echoSign. You can simply ignore setting up emails from the API and echoSign by default will place 'signature-block'(that includes a signature field and an email field as an inseparable block) for every signer's you have on your documents. If the same document needs to be signed by number of people, there is an option called counterSigner or so while creating widgets and you can specify just the signers(signer1, signer2..) as tags,
{{es:signer1:signature}},{{es:signer2:signature}}.... .The desired tags should be according to your business rule. For you it might just be the Signature or combination of name and signature, or whatsoever.
When the first signer signs the document, he has to enter his email (on the default signature block). He then has to log in on his email account and verify the signature. After this, echoSign will automatically pass the document signed by 1st signer to the next signer and so on.