I'm trying to create a LTV Enabled PDF Signature using Apache's PDFBox Detached Signature and the BouncyCastle API for the cryptographic signature itself.
So far I was able to make Adobe Reader display the "Signature is LTV enabled" message following these steps:
Retrieve revocation info (both CRLs and OCSP Responses, except for root certificates of course) for the signing certificate's full chain and for the timestamp authority certificate's full chain (used to add the signature's timestamp in step #4)
Include revocation info retrieved in step #1 as a signed attribute for the signature to be computed in Adobe OID "1.2.840.113583" format:
adbe-revocationInfoArchival OBJECT IDENTIFIER ::= {
adbe(1.2.840.113583) acrobat(1) security(1) 8 }
RevocationInfoArchival ::= SEQUENCE {
crl [0] EXPLICIT SEQUENCE of CRLs OPTIONAL,
ocsp [1] EXPLICIT SEQUENCE of OCSP Responses OPTIONAL,
otherRevInfo [2] EXPLICIT SEQUENCE of OtherRevInfo OPTIONAL
}
OtherRevInfo ::= SEQUENCE {
Type OBJECT IDENTIFIER
ValValue OCTET STRING
}
Perform the signature
Embed a qualified timestamp in the signature generated in the step #3
The previous steps' output gives me the "LTV Enabled" status in Adobe Reader:
When I check which data Adobe Reader used to validate the certificate chain validity it presents the expected "The selected certificate is considered valid because it has not been revoked as verified using the Online Certificate Status Protocol (OCSP) response that was embedded in the signature."
However, when I perform the same check for the Timestamp Authority's certificate chain it presents "The selected certificate is considered valid because it has not been revoked as verified in real-time using the Online Certificate Status Protocol (OCSP) obtained on-line."
The Signer's chain embedded CRLs/OCSPs are successfully used but the embedded TSA's chain CRLs/OCSPs are not.
This begs some questions that need to be answered:
Why are not the TSA embedded CRLs/OCSPs embedded used?
Do I have to place them elsewhere? If so, where?
Or do I have to ask the Timestamping authority to return the CRLs and/or OCSP responses as signed attribute within the timestamp token?
Related
I can encrypt a message in windows given a certificate with a private key with CryptMsgOpenToEncode and CryptMsgUpdate. This returns an ASN1 signature which contains the signature and the certificate enclosed in a full ASN1 message.
My problem now is that I am forced to use an external signing Web API site. Upon signing, the returned string from this Web site is the signature and the certificates in two separated messages, not within an ASN1.
The question is how to to build the message into a proper detached PKCS#7 signature (which would be put in a PDF file).
Must I build the ASN1 manually? I'm already using ASNC but I'm not sure how to build the complete message. Can I use openssl to combine certs + signature into a PKCS#7?
Thanks.
I am new to certificates and keystores.
What is the importance & working of keystores, and certificates for SAML SSO (in context of Spring boot SAML SSO)?
I see .jks, .pem, .cer, .der, etc. in use. What are these?
What is the importance & working of KeyStore, and certificates for SAML SSO (in context of Spring boot SAML SSO)?
These are used for Security implications for signing SAML assertions,
SAML protocol request and response.
Certificates in SAML SSO will be used to digitally sign the SAML
assertion/request/response and KeyStore is the persistent storage to
store the keys/certificates.
An assertion signed by the asserting party supports assertion
integrity, authentication of the asserting party to a SAML relying
party, and, if the signature is based on the SAML authority’s
public-private key pair, non-repudiation of origin.
A SAML protocol request or response message signed by the message
originator supports message integrity, authentication of message
origin to a destination, and, if the signature is based on the
originator's public-private key pair, non-repudiation of origin.
Certificates are also used for secure channel establishment
(SSL/TLS).
What are the .jks, .pem, .cer, .der, etc.?
.jks is extension to JAVA's proprietary KeyStore (JKS) format. JKS is
the database format for both the private key, and the associated
certificate or certificate chain. Till JAVA 8, by default, as
specified in the java.security file, keytool uses JKS as the format
of the key and certificate databases (KeyStore and TrustStores).
Since JAVA 9 the default KeyStore format has been changed to
PKCS12(extension .pkcs).
.pem, .cer, .der are the certificate/key types/extensions:
.PEM : The PEM extension is used for different types of X.509v3 files
which contain ASCII (Base64) armored data prefixed with a “—– BEGIN
…” line.
.DER : The DER extension is used for binary DER encoded certificates.
These files may also bear the CER or the CRT extension. Proper
English usage would be “I have a DER encoded certificate” not “I have
a DER certificate”.
.CRT : The CRT extension is used for certificates. The certificates
may be encoded as binary DER or as ASCII PEM. The CER and CRT
extensions are nearly synonymous. Most common among *nix systems.
CER : alternate form of .crt (Microsoft Convention) You can use MS to
convert .crt to .cer (.both DER encoded .cer, or base64[PEM] encoded
.cer) The .cer file extension is also recognized by IE as a command
to run a MS cryptoAPI command (specifically rundll32.exe
cryptext.dll,CryptExtOpenCER) which displays a dialogue for importing
and/or viewing certificate contents.
.KEY : The KEY extension is used both for public and private PKCS#8
keys. The keys may be encoded as binary DER or as ASCII PEM.
How can I check if a x509 certificate matches a CSR (if the certificate was generated based on a specific CSR) in Go? Do I need to generate a new certificate from the CSR and compare them?
If your signing request is in the DER format there's a couple of functions in the standard library you can use; first to parse the CSR (https://golang.org/pkg/crypto/x509/#ParseCertificateRequest) and then the certificate (https://golang.org/pkg/crypto/x509/#ParseCertificate). Once parsed you can compare the public key values.
Standard but important security note:
Please note that this DOES NOT validate the certificate in anyway. It may or may not be safe to use, and could have been substituted or altered.
I am currently developing an application that validates signature certificates (like in a pdf) with OCSP or CRL. These will most likely be leaf certificates, without the entire chain. Getting the url to either validation services proved simple enough.
To my understanding, both OCSP and CRL require the issuer of the certificate to validate it. So now I'm stuck because that is not included in the input. The AIA extension might include a URL to a CA certificate, but unfortunately this is the CA of the issuing certificate and not the certificate itself.
Is there any other way to get the issuer's certificate given only the leaf? Or are there some cases in which OCSP/CRL can validate without it?
Have a look at https://www.ietf.org/rfc/rfc2560.txt which details the requirements for an OCSP response to be considered valid:
The key
used to sign the response MUST belong to one of the following:
-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA
The first and third option both require the issuer cert. The second option does not. However I dont think that option is applicable to you situation. The link https://wiki.mozilla.org/CA:OCSP-TrustedResponder has details on what a trusted responder is and when it can actually be used.
I would like to ask when is the purpose of a certificate, like Server Authentication, Client Authentication, set for the certificate.
Is it when we generate the CSR or when it is signed by the CA?
The CSR is a Certificate Signing Request. If it is a PKCS#10 request (by far the most common type) it can indicate which extensions are requested and that can include the Extended Key Usage (aka purpose). But the CA ultimately decides what to include when it creates and signs the cert. It could choose not to issue a cert. It could issue a cert with a subset of the requested attributes. It could issue a cert that is completely different. It could issue a cert that is exactly what the CSR requested.