2

According to XML Signature Specification (3.2.2 "Signature Validation"), KeyInfo element may be signed:

"Note, KeyInfo (or some transformed version thereof) may be signed via a Reference element."

Here we can see an example of xml with such signature.

Are there any reasons to sign the certificate by itself?

What security risks does it eliminate?

dimmoborgir
  • 189
  • 1
  • 9

1 Answers1

2

Take a look at this clarifying section about attribute signingCertificate in XAdES. ETSI XAdES is built on top of XMLDSig to stablish the requirements of advanced signatures that remain valid over long periods

signingCertificate is mandatory when ds:KeyInfo is not present or does not contain the certificate used to sign, and serves the same purpose

7.2.2 The SigningCertificate element

In many real life environments users will be able to get from different CAs or even from the same CA, different certificates containing the same public key for different names. The prime advantage is that a user can use the same private key for different purposes. Multiple use of the private key is an advantage when a smart card is used to protect the private key, since the storage of a smart card is always limited. When several CAs are involved, each different certificate may contain a different identity, e.g. as a national or as an employee from a company. Thus when a private key is used for various purposes, the certificate is needed to clarify the context in which the private key was used when generating the signature. Where there is the possibility of multiple uses of private keys it is necessary for the signer to indicate to the verifier the precise certificate to be used.

Many current schemes simply add the certificate after the signed data and thus are subject to various substitution attacks. An example of a substitution attack is a "bad" CA that would issue a certificate to someone with the public key of someone else. If the certificate from the signer was simply appended to the signature and thus not protected by the signature, any one could substitute one certificate by another and the message would appear to be signed by some one else. In order to counter this kind of attack, the identifier of the certificate has to be protected by the digital signature from the signer.

Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • I have worked with those signing and certificates for 5 years but didn't know about multiple certificates with the same key or that kind of counter attack. There are always new things to learn :) – Thuan Jan 10 '17 at 16:19
  • @pedrofb, But if there is a "bad" (and trusted) CA and it issues a certificate for the attacker, the attacker could replace both the certificate **and the signature** which protects that certificate as well. Signing a certificate does not help in the case of "bad" CA, does it? – dimmoborgir Jan 10 '17 at 19:37
  • Indeed @dimmoborgir. You could only defend yourself by previously sending the public key to the recipient for a double verificacion. A "bad" CA can not create a valid signature since it does not owns the private key. But it is difficult for that CA to be considered "trusted". Requirements are very strict. Take a look at the requirement for trust service providers issuing certificates: http://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.00.00_20/en_31941101v010000a.pdf – pedrofb Jan 10 '17 at 20:16
  • @pedrofb. If "bad" CA isn't trusted (by the recipient), then replacing the original certificate (trusted) with another (untrusted) could be easily detected by the recipient (just verify cert validity). Thus, the described substitution attack will not succeed. Even without additional signature. – dimmoborgir Jan 11 '17 at 07:03
  • If the CA is not trusted you should not accept any signature of that CA by default. So substitution attack.will have no effect because recipient will reject all certificates( all are untrusted). Only those certificates previously sent to recipient, as I commented above, could be acceptef – pedrofb Jan 11 '17 at 07:12
  • Then, I can't understand what is the purpose of signing the certificate. Substitution attack is will have no effect even without signing the KeyInfo. Oh, maybe there is a purpose of signing KeyInfo **if it is not certificate**? Certificates are already protected (they contain signature of a trusted CA inside), but other types, such as KeyName, KeyValue, X509IssuerSerial, X509SubjectName are not. – dimmoborgir Jan 11 '17 at 07:59
  • 1
    @dimmoborgir the key to understand the substitution attack is your first comment. A "bad" and trusted CA. I think I've not commented with accuracy.. The CA can use the public key of the sender to issue a valid certificate, but can not substitute the signature because it does not have the private key, so a signed KeyInfo can not be replaced if is signed. If KeyInfo is not signed, a "bad" and trusted CA could replace it. So the assertion _"and the signature"_ of your first comment it is not possible – pedrofb Jan 11 '17 at 08:43