0

I am reading about XML signature from w3 page

As per my understanding, to Sign an XML:

  1. Create a Canonical XML of the XML Data to be signed.
  2. Create a hash (digest) of the Canonicalised XML Data using an algorithm mentioned in <DigestMethod/>. Hash will go inside <DigestValue>
  3. Encrypt above has using algorithm mentioned in <SignatureMethod/>. This algorithm will take Sender's private key as an input. Signature will go inside <SignatureValue>

To Verify (at receiver's end):

  1. Use the public key of the sender on the content of <SignatureValue> to get the hash.
  2. Calculate the hash of data (xPath/referece to data can be found in <Reference>) using algorithm <DigestMethod>
  3. Check if this has matches with hash in <DigestValue>

My Questions:

  1. Is my understanding correct?
  2. What is the role of <KeyInfo> in verifying signature given that sender's public key is sufficient for verifying?
pedrofb
  • 37,271
  • 5
  • 94
  • 142
dasfdsa
  • 7,102
  • 8
  • 51
  • 93
  • Hello @SKG, if any of the answers has been helpful or is correct, you can upvote, accept it, or provide feedback. It is not mandatory but it helps to maintain the site and get better answers. – pedrofb May 09 '18 at 08:31

2 Answers2

1

What is the role of <KeyInfo> in verifying signature given that sender's public key is sufficient for verifying?

The key has to be somewhere, right? And that's the place. It will contain the key to use for verifying the signature. As stated in the specification it is possible to skip the <KeyInfo> element:

If KeyInfo is omitted, the recipient is expected to be able to identify the key based on application context.

So when the <KeyInfo> is missing the application/user has to get the key from somewhere else.

Progman
  • 16,827
  • 6
  • 33
  • 48
1

As per my understanding, to Sign an XML:

  1. Create a Canonical XML of the XML Data to be signed.

  2. Create a hash (digest) of the Canonicalised XML Data using an algorithm mentioned in . Hash will go inside

  3. Encrypt above has using algorithm mentioned in . This algorithm will take Sender's private key as an input. Signature will go inside

It is not correct, see 3.1.2 Signature Generation section of the link you pointed.

The <SignatureValue> is calculated over the canonicalized content of a <SignedInfo> node, which includes the <SignatureMethod>, <CanonicalizationMethod>, and the References. The <Reference> element contains the <DigestMethod> and the <DigestValue>

The document is not encrypted, it is signed with the private key. It involves a similar cryptographic operation, but the padding mechanism is different. See https://crypto.stackexchange.com/questions/15997/is-rsa-encryption-with-a-private-key-the-same-as-signature-generation

What is the role of <KeyInfo> in verifying signature given that sender's public key is sufficient for verifying?

It contains the signing certificate corresponding to the private key used to sign the document.

The verifying party could verify the signature using signer's public key without extracting it from <KeyInfo> element, but it implies that the receiver has stored the public keys of each signer. The verifying party usually have a trusted list of Certificate Authority and checks that the signing certificate has been issued by one of these Authorities.

Note that a reference to <KeyInfo> is also included in the <SignedInfo> section, to know exactly which certificate signed the document (a public key can be included in several certificates)

Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142