SignedCms.ComputeSignature(cert) is very slow at the first request (rather intermittent) ,sometimes taking 20 sec. Tried the solution below, but didnt work since we cannot avoid that part of signature.
Message Signing using X509 certificate
Can anyone please throw some light on why this statement is very slow and is there any resolution for it.
Most likely this issue is related to signer (and counter-signer, if available) certificate validation, which requires chain building and revocation checking by downloading required objects (certificates, CRLs, OCSP). Network retireval may cause such delays. In addition, there might be issue with CDP/AIA extension URLs which contain inaccessible URLs.
What I would suggest to do: extract signer certificate to a file and run certutil command against this file:
certutil -verify -urlfetch path\signer.cer
and examine output. Pay attention to URL retrieval information. If presented, repeat this command against counter-signer (timestamp) certificates. If necessary, post certutil output here to get additional help.
Related
I am trying to implement signed code for some PS scripts, and I have a question about trusting certificates.
I know the "right" way to address this is for IT to use Group Policy to trust the certificate office wide. But many of my customers just don't really have that option. My thought is to provide instructions on using CertUtil.exe to do the job, but I wanted to be 100% sure that adding to trustedpublisher this way still results in the certificate being validated by the issuing authority at startup or login, so a revoked certificate in trusted publishers would in fact not be trusted, correct?
Also, give that the tool to be run is a management tool, my initial thought is to use the tool to drive CertUtil.exe. Basically the first time you use it it adds its own certificate, so you get some user interaction required on first use only. But the idea of code creating a trust for itself seems potentially sketchy, and would raise a little flag for me if I was on the other side wearing my IT hat. So, from a PS distribution model standpoint, is setting up one's own certificate considered appropriate, or verboten, or something of a gray area?
If I recall correctly revocation is almost immediate, with a possible short time lag due to pre-fetching. you can find more info on how exactly revocation is handled here - https://technet.microsoft.com/en-us/library/ee619754(v=ws.10).aspx
As far as adding your own cert I don't see an issue with it but if they require code signing for scripts it won't be able to do it's initial launch, personally I'd send the certutil stuff as a separate script (potentially a batch file) and keep the code you are actually sending over all signed.
I've been included in an analysis project or "cleaning up" of information which includes fields from certificates. I don't know how to access the actual certificates. I'd like to learn as much as I can about how/what can be verified in relation to a certificate. (I'm not doing security work, I just need to read the information.)
I have several spreadsheets with information including certificate data, all different sources with different fields. I'm trying to consolidate this information into a single table with as much verified as possible. Most records have Control Name, Serial Number, URL, etc., but based on the inconsistencies throughout other fields I think wrong or incomplete data has been added.
For instance, I'd like to verify that the expiration date on a spreadsheet is what is actually on the certificate. It also looks like one of the spreadsheets converted long serial numbers into a numeric data type, truncating(all 0's) the last half of the SN. Is there a way to look up all of a CN's certificates issued by a CA?
I'm very new to this, any tips would be appreciated.
Thank you
There is no general, public way I know of.
However, you might be able to get in touch with some CAs and do a research cooperation, but I doubt it. Handing out certificates to somebody else could be a privacy concern. And there's no chance you'll get certificates from all the CAs out there.
What you can do is obtain the certificates when they are used for publicly available services. For example if a certificate is issued to mail.example.com you could try to establish a TLS session to the host. You may have to try different ports, and maybe you are lucky and the host presents the certificate you are looking for.
My company develops an ERP for hospitals and because of some legislation changes throughout this weekend I've been reading a lot on digital signature because I need to solve the following scenario:
Each doctor will receive from the ministry of health a certificate (so there's no escape from it... government said so...) and all of his reports sent/stored in digital format must be signed with this certificate.
The certificates will be valid for one year. Each year upon renewing of the medical license, the certificate will be renewed.
Our main concern here is guaranteeing the source of the document (the sender is who he claims to be) but we must also make "impossible" (or at least infeasible) to change the content of the document (or at least that if it changes, we have to be able to tell that a modification occurred) and to "extracted and replicated" the signature...
My question is: how do I deal with this whole thing? What should I do?
PS: In your answer pls consider that:
The documents will persist far beyond the certificate lifetime.
The certificate might have been revoked. Documents signed before the revoke must still be valid
How a 3rd party would verify the integrity of the information (document + certification)
Is there not a security principle which states that information signed with a expired certificate is invalid or something?
I'm really new to this area and I might be asking the wrong question...
In brief, the document must be signed using CAdES, PAdES or XAdES (depending on data format) standard, where timestamping is applied and other measures are taken. These standards were designed specifically for tasks similar to yours so they address your concerns. I recommend that you read some articles about those formats. Unfortunately I don't have a link to share with you right now, but you can find a lot based on those abbreviations.
CAdES is based on PKCS#7/CMS (certificate-based signing of generic data with wrapping signatures) .
PAdES is an extension of PDF signing and is used specifically for PDF documents.
XAdES is similar to CAdES and can be used to sign XML documents and (more rarely) binary data.
[Disclosure: I work for CoSign by ARX.]
Your situation is common. You're raising a number of questions. My answers:
all of his reports sent/stored in digital format must be signed with this certificate.
You can digitally sign anything (any bundle of bits). The real issue is how can the recipient or auditor easily verify that the document:
was not modified since it was signed (integrity)
was signed by the right person (identity)
was signed with the right intent (signer's statement)
Machine readable data, eg form data, intermediate data, etc.
Signing: For info that is designed to be later machine-read (eg a form submission), store the info in XML and sign it using the XML Signing Standard: XAdES The CoSign Signature API (SAPI) directly supports signing XML docs.
Verifying There are many on-line XML digital signature verification services, Google for them. The SAPI api also supports verifying XML docs.
Human readable documents
Signing: For a "final" document that will be read by humans (but is stored digitally, can be included in searches, etc), PDF documents are the way to go. The PDF format supports digital signatures very well. There are many ways to add digital signatures to PDF documents. For developers, the CoSign Signature Web Agent is a web service (HTTPS + XML parameter document) that handles all the UI issues of signing.
Verifying: The most common way to verify the digital signatures of a pdf is to use the free Adobe Reader. (Not the expensive Adobe Acrobat.) Adobe Reader knows how to check the validity of the digital signatures and then tells the reader/signer/auditor that the signature is valid, the document was not changed since signed, etc.
Your other questions:
The documents will persist far beyond the certificate lifetime.
Yes, that is fine. Just like a "wet signature," once you've validly digitally signed a document, that document remains signed by you. -- Even if your signing certificate later expires. As part of the verification process, the date of signing is compared with the valid dates on the certificate.
The certificate might have been revoked. Documents signed before the revoke must still be valid
Yes, that is how standard digital signatures work. Even if a certificate is revoked, documents signed while the certificate was valid will remain signed. Because date/timestamps play such an important part of the validation process, there are 3rd party timestamping services available. But they are not used for most digital signatures. Instead, create explicit management procedures to make sure that the time server is properly setup with NTP to a good source and that the system is regularly checked and verified.
CoSign signs using a tamper-proof hw device. Its clock is synched using NTP.
How a 3rd party would verify the integrity of the information (document + certification)
As I discuss above, the whole verification question is important. That's why I recommend using XML or PDF as your document types. You could, for example, digitally sign your own system's internal data structure used to represent information. In this case the digital signature would be carried in a separate data structure. This is the "external signature" scenario. It all works fine, except that an auditor would need to either build his own sw to validate or trust that your sw is doing the validation properly. A better choice is to use a format that directly supports digital signatures and which can be easily verified.
Is there not a security principle which states that information signed with a expired certificate is invalid or something?
A proper digital signature system won't allow an expired certificate to be used to sign anything. Once something is signed, using a certificate that was valid at time of signing, it stays signed unless the document is subsequently changed.
I'm really new to this area and I might be asking the wrong question...
Other questions to ask: how do you add the signer's graphical signature to the document (XML or PDF)--people expect to see it. And how do you manage/administer the certificates? Server based signing is a good solution for this. Remember that certificates should not be stored in sw for any production systems. Instead, a Secure Signature Creation Device (something hw based) must be used.
You will also need to read the Baseline Profiles where there is a profile for long-term signatures.
There is a profile for each of the formats already mentioned by Eugene.
For example, if your document is PDF, you may use PAdES signatures and the LTA-Level specified in "PAdES Baseline Profile" document.
All of these documents are ETSI standards you can search for at: http://pda.etsi.org/pda/queryform.asp
I am curently working with a system, that has PDF signing option.
Now, when creating a complementary Android application, I've run into a bit of a conundrum: How do I check the validity of the certificate?
The problem is, that I'm interested whether the certificate was valid at the time of signing. Now I know, that Adobe has this kind of capability, but I'd like to know how to implement such a thing on my own.
I've succesfuly checked the status of the certificate against OCSP, but the only thing it gives me status of the certificate, whether or not it has been revoked/suspended and the date (which is incorect, and still puzzles me). I've also taken a look at CRL, but it seems, that it only has one record per certificate, meaning, it can't tell me whether or not a certificate was valid at a specific point of time.
Example:
Certificate 01 4D 44 5B - issued on 20.08.2012 - suspended on 21.08.2012 - reactivated on 22.08.2012
PDF document1 - signed on 20.08.2012
PDF document2 - signed on 21.08.2012
Now if we check the documents validity in Adobe Reader, PDF1 would show valid and PDF2 as invalid.
How does Adobe knows, and how do I find out the same information? Maybe there is some OS programm, who's source I could take a look into, to find this out?
This usually done by embedding a timestamp in the digital signature, usually itself signed by a different but trusted CA, like that used in Microsoft authenticode. This timestamp is compared to the validity period for the certificate to determine whether the certificate was valid at the time of signing.
Also see How does countersign in code signing work? or the signtool.exe /t option for more discussion on this.
I have to deal with certificates issued by the Swiss post office on USB tokens. There deliver two certificates on the same token. In their intended usage fields, one has "non repudiation" and the other "digital signature".
Now, I can't understand what the practical difference between the two are: I've always seen both in the same certificate, never two certs for the same identity each with one of the roles. In fact, I can't imagine a scenario where non-repudiation and digital signature aren't the same, for all practical matter, the same thing.
Could anyone explain to me what the difference is, please ? And if you had a suggestion about in what situation one should be picked over the other, that would help as well.s
I realise this question is a bit old, but I think I can shed some much-needed light on the question.
The non-repudiation value in the keyUsage attribute relates to the whole certificate, not any purpose in particular. The presence of the non-repudiation flag indicates that the private key has sufficient protections in place that the entity named in the certificate cannot later repudiate—deny—actions they take with the certificate. The presence of the flag doesn't prevent repudiation, rather it indicates that repudiation isn't likely to survive reasonable scrutiny.
So in this specific case, the CA is giving the user the option of a certificate that does or does not include the non-repudiation element. If you want to assert to those verifying the signature that you can't easily deny it was you who signed it (the USB token is the key enabler here), use the non-repudiation certificate. Otherwise, use the certificate marked for digital signatures. (Depending on the other attributes in the certificate, you may or may not be able to sign documents with either or both certificates.)
See Wikipedia: http://en.wikipedia.org/wiki/Non-repudiation
See also the relevant RFC: http://www.faqs.org/rfcs/rfc3280.html (section 4.2.1.3)
I talked to the guy who implemented it and, apparently, they intended the "non-repudiation" cert for /really/ signing documents and the "digital signature" one to be used for authentication.
"digital signature" means that you can guarantee the origin of the document or the id of the user; this is AUTHENTICATION.
"non repudiation" means that the document is approved, this is content commitment also called ELECTRONIC SIGNATURE (not digital signature).
Hope this helps because one's always asked this question even in 2013.
Interesting question, and your thoughts match my own.
I've found a reference at IBM here about key usage, but I still can't really get my head around the distinction.
The best that I can phrase my understanding having read the article is that a non-repudiation usage means "I really meant to sign this, and I really understand the implications of signing this."
Sorry this isn't a complete answer, but I hope it helps.
EDIT 4th April 2014
I just got given more points again. The answer from #Calrion is much better, so send any +1s that way.
"digital signature" should be used for authentication (it was you, who signed this), while "non repudiation" means that you know what you was signed.
If you use your private certificate for authentication (against some server) the authentication works following way: During establishing the connection your browser (or other SW) signed some random data provided by server to prove that it was you on the other side. But the key point is that you have no control which data you are signing. Thus the server can you send instead of random data send "I, Petr Novonty, give all my money to James Clark."
To avoid this, key used for signing some documents should have "non repudiation" and not "digital signature" bits set.
This page gives somewhat clear descriptions of all the key usages:
https://www.ibm.com/support/knowledgecenter/en/SSKTMJ_9.0.1/admin/conf_keyusageextensionsandextendedkeyusage_r.html.
Keep in mind, that X.509 renamed the nonRepudiation bit in contentCommitment. This seems to be better than a description via "non". So this remark supports the answer given by Franck Leroy.
Note that they are simple bits, their names give only indications for the key usage. Some explanations of these bits are given in RFC 5280. But how to interpret distinctions between these two is finally left to the certificate issuer. RFC 5280 says on this "Further distinctions between the digitalSignature and nonRepudiation bits may be provided in specific certificate policies."
https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3