Java XML Signature API and Smart Card - java

I'm prototyping on how to sign XML documents with the Java XML Signature API and I have it working fine when working with a private key from a local keystore but I'm looking for some assistance in how to reach my ultimate goal:
How/where to extend the JSR-105 implementation so that I could sign the XML document with a Smart Card reader (where the private key resides behind a PIN code)? The https://docs.oracle.com/javase/8/docs/technotes/guides/security/xmldsig/overview.html indicates that it should be possible.
The implementation I'm working with essentially runs a REST interface on the localhost where you POST the job in JSON format in order to sign stuff. I'm looking for a way to hook in the signing step so that the Java API basic implementation does the c14n stuff and digests the references and passes "the right stuff" to my implementation for a REST-roundtrip to the card service and then (if the PIN is correct), signs the data and I extract the result and pass it back in order for the Java API to take over and insert the signature in the correct location in the document.
If anyone has done something like this, I would appreciate pointers instead of my having to create decorators for everything and trying to breakpoint myself through the entire reference implementation.
Thanks in advance,
Nik

Related

How to read standard fields in the docusign api

I am implementing qsjava application of docusign, as part of the application it is taking the pdf file from local folder i.e,World_Wide_Corp_lorem.pdf. I want to take that file from my accound Link.
I have created the Template and I have added the standard fields like text box.
Here my question is in the api link i.e, https://demo.docusign.net/restapi/v2.1/accounts/accountid/templates/teplateid, I am not getting the statndard fild that I have added in the template, from which api I will get it.
Once I got that field how can I read that my account template api and use that template in my application.
I'll answer your question, but I don't think that's what you are trying to do.
To retrieve the bits of documents inside templates, you can use this endpoint:
GET /restapi/v2.1/accounts/{accountId}/templates/{templateId}/documents/{documentId}
You need to know the documentId of your document, which is typically a number, if you set it yourself you can use "1", "2" etc.a
Now, I wonder if what you want to do is use this template to have someone sign an envelope using that template? that doesn't require you to download the bits.
See this code example that shows how to do this with your template if that's what you're after.

Is there a Java API on IBM Domino to encrypt/decrypt a Notes item on the server?

I need to write a Java agent who will be signed with the server.id and will run on the server. This code should be able to encrypt and decrypt a NotesItem with the private and public keys stored in the server id file.
This is about the same, what the DAOS task is doing with the attachments.
Is this possible?
Thanks!
The Designer Help article for NotesDocument.Encrypt suggests the answer is yes.
See: https://www.ibm.com/support/knowledgecenter/en/SSVRGU_9.0.1/basic/H_ENCRYPT_METHOD.html
I've never tried it, but going by the above article: If you don't set the EncryptionKeys property on the document, and call Encrypt in code running on the server, it should encrypt items using the server id's public key.
Edit:
I've just noticed you specifically asked about Java. The documentation for the Java method Document.encrypt() is similar enough to the LotusScript documentation that the above should still apply.
Again, thanks to all who helped. The solution is really simple (after you know how it works) ...
Add a Notes item in the form
Name "PublicEncryptionKeys"
Type "Names"
Value ServerName, e.g. "Server/ACME"
All item which needs to be encrypted
Type "Password"
Set Security Options "Enable encryption for this field"
Then every time, the document is saved in the Notes client, the field(s) are encrypted with the public key of the server.
In the Server add-on, there is nothing to do. Just use getItemValue() which will transparently decrypt the contents of the items.

adding digital signature to PDF with visible timestamp and Reason field using ESIG/DSS

I am trying to understand and implement a solution based on European Commission-sponsored Digital Signature Service project. I currently have succeeded in using the abstraction provided by the DSS-DEMO application, mentioned in the aforementioned github link, with the help of Nowina NexU client software. My wish is to digitally sign a PDF document with the following configuration:
no container
PAdES signature form
enveloped
PAdES_BASELINE_LT signature level
SHA256 digest algorithm
I want the signature to have a visible part, i.e. to be seen on the first page of the document. This is somewhat demonstrated here. Personally, I need the actual signing timestamp and the name of the signer from her certificate. In the above demonstration this is done by providing "parameters" to the signing function.
I also want to fill the Reason field of the signature - it is then subsequently displayed when you view the Signature properties with a program like Adobe Acrobat Reader.
My problems so far are the following, and I can't seem to find neither examples nor other sort of information about them.
If I want to display the signing timestamp that I would get from a Timestamp Authority service, how would I get it, since the communication with the timestamp server is done during the signing process, i.e. after specifying the parameters as I mention above. I guess I have to dig into DSS code and do all the steps done there for me myself.
Currently, a strange thing happens. It appears that the signatures are deemed valid, or at least UNKNOWN, when I specify a hardcoded Reason (like 'testtest'), or no Reason at all. When I fill it from results of something else, the signature is not valid. Because things like this don't usually happen by magic, I must be doing something awfully wrong.
The code is organized approximately like this - there's a REST communication between two machines - a server and a client with NexU installed. NexU does all the communication with the smart card or any other certificate store on the client machine - it exchanges the digest value and the signed digest value with the server. There are, among others, two specific phases in the server code :
getDataToSign - here a digest is calculated from the PDF content
signDocument - here the actual signing - (embedding of the signature into the document, i guess?) takes place.
I am giving to both these phases a host of parameters, that, among other things, specify the signing timestamp, the Reason, and the visual parameters of the text I want to appear on the first page. I am doing this with the same parameters for both of the phases (because I am not sure on which phase I should give which)
My signing date - isn't it logical for it to be as close to the timestamp authority server's timestamp as can be? Okay - I am setting it to the current timestamp of my own server at the time of the beginning of the signing process.
I am setting Reason using PAdESSignatureParameters.setReason.
Any helpful insight is appreciated - thanks.
I have solved the weird issue with the Reason field of the Signature.
I don't seem to see any way around the Signing Date being different from the Timestamping Authority-provided Timestamp.
Explanation follows.
As far as the first case, it was my fault. To elaborate, following my understanding, the signature parameters are provided to the DSS methods two times using SigningService.fillParameters() method.
in SigningService.getDataToSign(...) and then
in SigningService.signDocument(...)
This is important to be done in both methods, because during the first time, the hash/digest of the document-to-be-signed is calculated. Since I have chosen the signature to be enveloped, i.e. to be contained within the document that is going to be signed, we need to first apply the signature, and then calculate the digest basing on that "final" document.
As far as I saw in the DSS code (approximately), the in-memory representation of the uploaded PDF is signed, and its digest is calculated, during getDataToSign - but the outcome is discarded.
During the actual signDocument method (in between, the digest has travelled back to the client with NexU installed, and returned back to the server signed), the uploaded PDF is signed again, its digest calculated again, but this time the actual signed digest (we got from the client) is also applied to the document - and the in-memory outcome of this operation is sent back to the client as a signed PDF document.
What I was doing wrong is that during the first time, I was losing the variable that I was going to add as the Reason (it was lost somewhere in the model attributes - i was not passing it somewhere in between requests), with the result of my first map of parameters passed to getDataToSign differing from the second map of parameters - so it is only logical, that the actual hash/digest of the document was different from the digest in the saved signature (because at the time the digest-to-be-signed was calculated, i wasn't passing the Reason). That's why when I was passing a hardcoded value, because it was hardcoded, it was present during both calls to fillParameters. It was such a stupid mistake, I know. I should have known this because there was absolutely nothing about any difficulties with passing Reason (or other fields like Location) to the Signature.
BTW the signing is done using Apache PDFBox, and it is done incrementally.
As for the second thing, we decided to leave it as it is, although there is a comparatively impressive gap between the signing timestamp and the timestamp authority one. I don't really know what should be the allowed gaps in cases like this. I guess that this happens because
My server might have a slightly off-normal local time
Because the whole process of signing is going on between two machines (server and client with NexU installed, as well as the smart card), and because there are different dialog windows appearing asking for password etc. - it all postpones the actual signing and the call to the timestamping authority is done during the very last step. Of course, I am not sure if it is an issue, since theoretically timestamping authority doesn't know about the actual contents being changed - the previous error would have been triggered in that case..
That's more like it - of course I am open to other comments and answers. Thank you!

How to invoke applications on BlackBerry

I'm new on this world of BlackBerry and the thing is that i have a byte array of certain file that can be anything (picture, pdf, txt ...) and need to be shown. How can i execute applications related with the specific extention? In other words how can i invoke an application and give it the byte array to be displayed as the original file?
I also have the extention or file type.
I have tried to open the file using browsers but it always return timeout and that's not the idea.
Here is something like my question but it has not a final response. I'm developing for BlackBerry Curve.
I have never used it, but I think the appropriate API for this is the Content Handler API, most commonly referred to as CHAPI I think. Look for documentation of javax.microedition.content. Here is a link that will take you to the ContentHandler class.
I suggest that you look for the chapidemo sample for more information. It should have come with your tooling, if not, here it is on github: chapidemo sample.

How to get URL in Java using the Remember The Milk API?

I want to write an Android application that uses the Remember the Milk API, but I can't figure out how to use the API's app authentication scheme. How do I generate the URL to authenticate my application with RTM?
I was looking for this too, and seems it was right in front of me. https://www.rememberthemilk.com/services/api/request.rest.rtm is where it explains the format.
Basically it's https://api.rememberthemilk.com/services/rest/ and then whatever you want to send.
So it would seem you'd start by getting the frob using https://api.rememberthemilk.com/services/rest/?method=rtm.auth.getFrob&api_key=123456789
Then when you get the frob back you'd use it to get a token with https://api.rememberthemilk.com/services/rest/?method=rtm.auth.getToken&api_key=123456789&frob=0a56717c3561e53584f292bb7081a533c197270c
Of course you'd replace that random key and frob with your actual key and whatever you get back from getFrob.
I'm about to try using this myself, so I'll try and post back if anything needs to be changed.

Categories