XML Committee Revised Report

8/3/2019 XML Committee Revised Report

1/26

1

Revised Report of the Committee onNew PKI based Digital / Electronic Signature Schemes

Ver 2.1September 2011

SUBMITTED TO

Controller of Certifying AuthoritiesDepartment of Information Technology

Ministry of Communications and Information Technology


2/26

2

Table of Contents

INTRODUCTION ....................................................................................................................................................... 31.1 BACKGROUND .................................................................................................................................................. 31.2 SCOPE AND PURPOSE OF THE REPORT .............................................................................................................. 31.3 XMLSIGNATURE OVERVIEW .......................................................................................................................... 31.4 CMSSIGNATURE OVERVIEW........................................................................................................................... 41.5 ISSUES.............................................................................................................................................................. 4

2 INFORMATION TECHNOLOGY ACTPROVISION FOR NEW SIGNATURE TYPES .................... 52.1 DIGITAL AND ELECTRONIC SIGNATURES FROM ITACT.................................................................................... 5

2.1.1 Digital Signature (Section 3) ................................................................................................................. 52.1.2 Electronic Signature (Section 3A) .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... . 5

2.2 ADMISSIBILITY OF XMLSIGNATURES UNDER ITACT .................................................................................... 62.3 CONSIDERING CMSSIGNATURES UNDER ITACT ............................................................................................ 6

3 XML SIGNATURESDETAILED EXAMINATION AND RECOMMENDATIONS ............................. 63.1 SIGNEDINFO ..................................................................................................................................................... 8

3.1.1 Canonicalization method ....................................................................................................................... 83.1.2 Signature Method ................................................................................................................................... 93.1.3 Reference ............................................................................................................................................... 9

3.2 SIGNATUREVALUE ......................................................................................................................................... 113.3 KEYINFO ........................................................................................................................................................ 113.4 OBJECT .......................................................................................................................................................... 113.5 ENVELOPED,ENVELOPING AND DETACHED SIGNATURE ................................................................................ 123.6 SUMMARY OF RECOMMENDATION FOR XMLSIGNATURES ........................................................................ 133.7 PROPOSED XML DEFINITION, SIGNATURE CREATION AND VERIFICATION METHODS ...................................... 13

4 CMS SIGNATURESDETAILED EXAMINATION AND RECOMMENDATIONS ........................... 144.1 DIFFERENCE BETWEEN PKCS#7 AND CMS ................................................................................................... 14

4.1.1 References for CMS: ............................................................................................................................ 144.1.2

RFC2315 .............................................................................................................................................. 14

4.1.3 RFC2630 .............................................................................................................................................. 14 4.1.4 RFC 3369 ............................................................................................................................................. 14 4.1.5 RFC 3852 ............................................................................................................................................. 14 4.1.6 RFC 5652 ............................................................................................................................................. 15

4.2 INFERENCE..................................................................................................................................................... 154.3 RECOMMENDATIONS...................................................................................................................................... 15

5 REFERENCES ................................................................................................................................................. 165.1 NORMATIVE REFERENCES.............................................................................................................................. 165.2 INFORMATIVE REFERENCES ........................................................................................................................... 16

6 COMMITTEE MEMBERS ............................................................................................................................ 177 ACKNOWLEDGEMENTS ............................................................................................................................. 17ANNEXURE I ............................................................................................................................................................ 18PROPOSED RULES FOR XML SIGNATURE CREATION AND VERIFICATION ...................................... 18ANNEXURE 2 ........................................................................................................................................................... 26


3/26

3

Introduction

1.1 Background

The Information Technology Act came into effect in 2000 and was subsequently modified in

2008. At present, PKCS#7 based signatures are the only valid signatures as per standards underthe IT Act. Several PKI based new signatures schemes are available, which include CMS and

XML signatures. The XML signatures are proposed to be used in e-governance application.

The CMS based signatures are suitable for Long term archival and Time Stamping. IETF andW3C (W3C XML Signature, 2003), has developed an XML compliant syntax for representing

XML signatures.

A detailed technical evaluation of these signatures, therefore are needed to be conducted before

adoption of these signatures under IT ACT. A committee was setup by CCA to examine this via

an Office Memorandum dated 19th

July 2010.

Several meetings of the committee were held where different issues related to the legal validitywere discussed. Committee also consulted with national and international experts and examined

applicable international best practices in the area. This report summarizes the conclusions of themeetings and work done thereafter. The report contains specific recommendations of the

committee to bring the XML Signatures and CMS Signatures under the ambit of the IT Act.

Throughout the report, the terms and definition used have been taken from the sources such asInternet Engineering Task Force (IETF) and World Wide Web Consortium (W3C). The details

of the same are available in section 5.

1.2 Scope and Purpose of the Report

The scope of the committee is to examine and technically evaluate PKI based XML Signaturesfor determining whether they are legally valid under the IT Act. If not found to fulfill the

requirements, the committee should identify and suggest how they can be brought under the

ambit of the IT Act and submit recommendations accordingly to the Controller of Certifying

Authorities. Also the Committee examined CMS Signatures with respect to same aspects.

1.3 XML Signature Overview

XML Signature is used for ensuring message integrity, authentication, and non-repudiation.

XML Signature uses same hashing and cryptographic algorithms as used in Digital Signature asper IT Act. XML Signature defines how to apply well established hashing and cryptographicalgorithms to XML documents. This includes a standardized way to represent signatures, and

information about the associated key(s). XML signature is independent of whether the signed

resource is an XML resource or not. A single XML signature may cover several resources, whereeach resource may be an XML document, a part of an XML document, or a binary resource.

XML Signature defines a standard interoperable format for representing signatures in XML and

provides mechanisms for efficiently signing to XML resources. XML Signatures are indirectsignatures.


4/26

4

1.4 CMS Signature Overview

Cryptographic Message Syntax (CMS) is an Internet Engineering Task Force (IETF) standardthat is used to digitally sign, authenticate, or encrypt arbitrary message content. The CMS is

derived from PKCS#7 version 1.5, which was originally published as an RSA LaboratoriesTechnical Note in November 1993. Since that time, the IETF has taken responsibility for the

development and maintenance of the CMS.

PKCS#7, the precursor of CMS, describes encapsulation syntax for data protection. It supports

digital signatures and encryption. Digital Signature, as described by PKCS#7 is the only one type

of signature currently approved by IT Act 2000. With this, standard asymmetric technique is

used for Digital signature. It can

host multiple signatures (hierarchical or parallel)

can carry certificates, CRLs, timestamps and other information. make use of recursive format

The PKCS#7 permits recursion, for example, one envelope can be nested inside another, or one

party can sign some previously enveloped digital data. It also allows arbitrary attributes, suchas signing time, to be authenticated along with the content of a message. It also provides for

other attributes such as counter signatures to be associated with a signature.

The current CMS standard, RFC 5652 has added many features to the original PKCS#7, some ofwhich are backward compatible but some are not.

1.5 Issues

The following issues were discussed by the members of the committee:

Admissibility of XML and CMS Signatures as electronic signatures as per Section 3A orDigital Signature under Section 3 of IT Act.

Whether XML and CMS signing follows "What You See is What You Sign" principledoes the IT Act explicitly mandate it, if not should it be amended to mandate it; and what

are the implications of such a mandate on XML and CMS signatures

What modalities need to be adopted for accepting XML and CMS signatures undersection 3/3A of IT Act.

What features of XML Signatures are to be considered for reliability and acceptance

under Section 3A of IT Act. What are the features of XML Signatures that might violatethe principle of reliability of the signatures as laid out by the IT Act and how shouldthese be addressed


5/26

5

2 Information Technology Act Provision for New SignatureTypes

The following sections examine the issues in greater details and contain specific

recommendations by the Committee. The recommendations are hi-lighted with a box and a greybackground. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in

this report are to be interpreted as described in RFC2119.

2.1 Digital and Electronic Signatures from IT Act

The following two sub-sections give the definition of digital and electronic signatures as per theIT Act.

2.1.1 Digital Signature (Section 3)

3 (1) Subject to the provisions of this section any subscriber may authenticate an electronic

record by affixing his digital signature.(2) The authentication of the electronic record shall be effected by the use of asymmetric

crypto system and hash function which envelop and transform the initial electronic recordinto another electronic record.

ExplanationFor the purposes of this sub-section, "hash function" means an algorithm

mapping or translation of one sequence of bits into another, generally smaller, set knownas "hash result" such that an electronic record yields the same hash result every time the

algorithm is executed with the same electronic record as its input making it

computationally infeasible

(a) to derive or reconstruct the original electronic record from the hash resultproduced by the algorithm;

(b) that two electronic records can produce the same hash result using the algorithm.(3) Any person by the use of a public key of the subscriber can verify the electronicrecord.

(4) The private key and the public key are unique to the subscriber and constitute a

functioning key pair.

2.1.2 Electronic Signature (Section 3A)

3A (1) Notwithstanding anything contained in section 3, but subject to the provisions of sub-

section (2), a subscriber may authenticate any electronic record by such electronic

signature or electronic authentication technique which

(a) is considered reliable; and(b) may be specified in the Second Schedule.

(2) For the purposes of this section any electronic signature or electronic authentication

technique shall be considered reliable if(a) the signature creation data or the authentication data are, within the context in

which they are used, linked to the signatory or, as the case may be, the authenticator

and to no other person;


6/26

6

(b) the signature creation data or the authentication data were, at the time of signing,

under the control of the signatory or, as the case may be, the authenticator and of noother person;

(c) any alteration to the electronic signature made after affixing such signature is

detectable;

(d) any alteration to the information made after its authentication by electronicsignature is detectable; and

(e) it fulfils such other conditions which may be prescribed

2.2 Admissibility of XML Signatures under IT Act

XML signatures make use of asymmetric key encryption and hashing (as mentioned in thesection 3), however the procedure for the creation and verification of XML signatures is different

from procedure for creating and verification of Digital Signature

Format and procedure for creating XML signature is different from that stated under

Section 3 of IT Act even though it follows same hashing and cryptographic algorithms.

Committee is of the opinion that rules can be formulated under section 3A to add XMLSignatures as Electronic Signature.

2.3 Considering CMS Signatures under IT ActIT Act 2000, recognizes only PKCS#7 signatures as valid signatures. The differences between

PKCS#7 and CMS signatures are not very significant. The Rules do not directly cover CMS

signatures. Therefore, the committee recommends that:

Existing Rules under Information Technology (Certifying Authorities) Rules 2000 framed

under Section 87 can be amended to explicitly mention that CMS Signatures as legally

valid, however this requires a further detailed examination.

3 XML Signatures Detailed Examination andRecommendations

This section examines the constituents of XML Signatures in details and gives recommendationsof the committee on their usage. Normative definition of XML Signature can be found in RFC

3275(Extensible Markup Language) XML-Signature Syntax and Processing, Eastlake et al.,

March 2002. This section records all the recommendations of this committee that deviate fromor further qualify the standard definition given in RFC 3275. If this section or Annexure I

Proposed rules for XML signature creation and verification does not mention any particular

aspect of XML Signature it may be assumed that the definition and interpretation given in RFC

3275 holds.

The following describes the structure of an XML signature.


7/26

7

(

()?

+

(

(KeyName)

(KeyValue)

(RetrievalMethod)

(

(X509IssuerSerial)

(X509SKI)

(X509SubjectName)

(X509Certificate)(X509CRL)

(X509IssuerName)

(X509SerialNumber)

)

)?

()*

Where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*"

denotes zero or more occurrences

Signature Composition

A XML signature itself is a XML document. It consists of four elements, two of which aremandatory.

1. The SignedInfo sub-document specifies the data to be signed. This is a mandatoryelement

2. SignatureValue yields the digital signature itself. This is also a mandatory element3. An optional KeyInfo node contains information about the key used to sign the

document.

4. A list of Object nodes completes the document. This list may just have any numberof

elements, or the list may be empty.

Apart from the two mandatory elements, the committee recommends that KeyInfo MUST

be used in XML Signature. The KeyInfo will be used for storing the X.509 certificate of the

signer. Accordingly, X509 Certificate MUST be used inside KeyInfo element. The Object

element is still optional and can be used for storing values such as signature time. Use of

this element is up to the application.


8/26

8

3.1 SignedInfo

The SignedInfo element is the one that is actually signed. It contains one or more Referenceelements, the canonicalization algorithm identifier, and the signature algorithm identifier. The

Canonicalization algorithm is used to convert the SignedInfo element into a standard form before

it is signed or verified. The Signature algorithm typically includes a digest algorithm and an

asymmetric encryption algorithm. The digest algorithm is applied after calculating the canonicalform of the SignedInfo in both creation and verification of XML signatures

The SignedInfo sub-tree contains three elements:

3.1.1 Canonicalization method

Canonicalization is one possible transform that may be applied to an XML resource before

calculating the digest. The need for XML canonicalization is because of the fact that two

logically equivalent XML resources may differ in physical representation. Such variations in

physical representation may for instance be due to the use of different character encodings orinsignificant structural differences. Canonicalization methods define a normal form, that is, the

canonical form, into which logically equivalent documents, can be converted to obtain the samephysical representation. There are two main canonicalization methods, Canonical XML andExclusive XML Canonicalization

In order to be able to verify the signature of an XML resource that has had its representationchanged, it is essential that canonicalization is performed as part of the XML signature creation

and verification processes

Canonical XML and Exclusive XML CanonicalizationCanonicalization is a process for converting data that has more than one possible representation

into a "standard", "normal", or canonical form. This can be done to compare differentrepresentations for equivalence, to count the number of distinct data structures, to improve theefficiency of various algorithms by eliminating repeated calculations, or to make it possible to

impose a meaningful sorting order.

Canonical XML and Exclusive XML Canonicalization are two variations of canonicalisation

(though suitable for different contexts) and each of these has two further variants -- with or

without comments. As the name implies, they include and exclude the comments in thecanonicalised forms respectively.

Inclusive XML canonicalization guarantees that all declarations that might be used will be

unambiguously specified. If a signed XML document is put into another XML document that hasother declarations, Inclusive Canonicalization will copy those and the signature will become

invalid. Exclusive Canonicalization establishes the name spaces actually used and just includes

those. Use of Exclusive Canonicalization ensures that signatures created for any sub-document

of an XML document can be verified independent of the context. This capability is important toensure that the substantive content of an XML sub-document can be validated as unmodified

even if that sub-document is moved into a new document or moved in relation to other content in


9/26

9

the same document. One anticipated use of this capability is to allow intermediaries to add

additional signatures or XML wrappers.

A Signature which appears to authenticate the desired data with the desired key, DigestMethod,

and SignatureMethod, can be meaningless if a strange and badly understood Canonicalization

Method is used.

The canonicalization algorithms are used with XML Signatures in two ways. They can be

specified as the Canonicalization Method for the Signature (in which case canonicalization isapplied specifically to the SignedInfo element). They can also be applied as a Transform within a

Reference, in which case canonicalization applies to the specific data being signed for a given

Reference. To avoid namespace problems, Exclusive XML Canonicalization should be used inboth places

As for whether to include comments in canonicalization, comments inherently do not form a part

of the data, and the signer is not really signing on the comments in the XML. Comments are

useful only for someone inspecting the XML rather than for someone who is looking at therendered view of the XML document. Therefore, any change to the comment should not

invalidate the signature.

Cannonicalization is requirement for XML signature. The committee recommends that

canonicalization MUST be used and it MUST be Exclusive Canonicalization Without

Comments.

3.1.2 Signature Method

The SignatureMethod gives the algorithms used to obtain the signature. The XML signaturestandard itself does not declare any specific mathematical signature functions. The commonlyused signature methods are DSA with SHA1, RSA with SHA1 or HMAC13 with SHA1.

Since the Interoperability guidelines for digital signature only recommend RSA with

SHA256, the committee recommends that the signature method MUST be RSA with

SHA256 for XML signature.

3.1.3 Reference

A URI identifies a resource either by location, or a name, or both. More often than not, most of

us use URIs that defines a location to a resource. A URL is a specialization of URI that defines

the network location of a specific resource. The URL defines how the resource can be obtained.

Each Reference element includes a Uniform Resource Identifier (URI), a hash value

(DigestValue), the digest algorithm identifier (DigestMethod), and an optional list of Transformelements. The URI is a pointer that identifies the data to be signed. It can point to an element

inside an XML message, an element inside the Signature element such as Object or KeyInfo, or

resources located in the Internet. The DigestValue contains a hash value after applying the digest
http://en.wikipedia.org/wiki/Uniform_Resource_Identifierhttp://gbiv.com/protocols/uri/rfc/rfc3986.html#URLvsURNhttp://gbiv.com/protocols/uri/rfc/rfc3986.html#URLvsURNhttp://en.wikipedia.org/wiki/Uniform_Resource_Identifier


10/26

10

algorithm to the data pointed by its URI. If the Transform element exists, it includes an ordered

list of transform algorithms that are applied to the data before being digested.

3.1.3.1URI attributeThe URI attribute identifies a data object using a URI-Reference. URL can point to data in the

same document or different document. In any case the data pointed by it is hashed. The hash isalso verified as a part of signature verification process

3.1.3.2DigestMethod

The last element within the Reference element is the DigestMethod element, used for specifyingthe digest algorithm being used. The only digest algorithm required to be supported is SHA-256.

However, there have also been defined identifiers for additional algorithms and several

implementations support SHA-256

As of now the Interoperability guidelines for digital signature only recommends SHA256,

the committee recommends that the DigestMethod MUST be SHA256 or higher as notified

under the IT Act.

3.1.3.3DigestValueThis is the digest value of the data referenced by the URI and digested using the DigestMethod

described above.

3.1.3.4TransformationApart from canonicalization, several other transformations may be applied to a resource. Theseinclude Base64 decoding, XPath filtering, and Extensible Stylesheet Language Transformations

(XSLT). Furthermore, there is a decryption transform that enables XML Signature applications

to distinguish between XML structures that were encrypted before the signature was calculated

and structures that were encrypted after the signature was calculated.

XML signature supports selective signature processing. The use of XPath or Xpointer allows

inclusion or exclusion of portions of content from the signature. In the case of XPath transform,it is possible that it evaluates to zero or false for every node, so it ends up selecting nothing. So

even though the signature seems to sign some data, it actually doesn't. XSLT transform also may

cause nothing to be selected for signing. This issue is particularly crucial in the case of legaldisputes.

A related issue is that of What You See Is What You Sign (or WYSIWYS). This is a

fundamental guiding principle behind the Indian IT Act, though it is not spelt out explicitly. Itrequires that user should be shown what he is signing and the actual data that is being signed

should match with what the user is shown.


11/26

11

The committee recommends that in case of a human user signing XML data (as opposed to

an application signing the data without human interaction), the data being signed

SHOULD be rendered and presented to the user using XSLT and that the XSLT SHOULD

also be included in the signing process by incorporating it by reference. If the XML Data

being signed includes some transforms, then XSLT shall be the last of the transforms. This

shall ensure that the data being rendered to the user is after the specified transformationsare performed. The rendering of non XML-resource shall be implemented using

MimeType attribute mentioned in the object.

3.2 SignatureValue

The SignatureValue XML node is a very simple object: It contains just the base-64 encoded

value of the encrypted digest (signature)

3.3 KeyInfo

The KeyInfo node holds information about the key used to create the signature. Informationabout the owner of the digital key etc. can be stored here, which may be used to provide

information about the key to be used for verifying the signature. This information may beprovided by identifying the key by name, by including the raw public key itself, and/or by

including (or referencing) an X.509 certificate. Using the PGPData element, a PGP key packetcan also be included. Furthermore, the RetrievalMethod element may be used to reference

KeyInfo information at another location (i.e., within another KeyInfo element).

The committee recommends use of public-private key cryptographic technique in

combination with X.509v3 digital signature certificate provided by a licensed CA in

forming XML Signature. Furthermore, though KeyInfo is optional according to XML

Signature schema, the committee recommends that KeyInfo element with the

X509Certificate option MUST be present in the XMLSignature

3.4 Object

The Signature may contain zero or more Object elements. The Object element may contain

SignatureProperties or Manifest or any arbitrary data. The SignatureProperty identifies propertiesof the signature itself such as the date/time when the signature was created. The Manifest

element includes one or more Reference elements same as the Reference element within the

SignedInfo. They are semantically equal; however, each Reference in the SignedInfo has to be

validated in order to consider a valid signature. On the other hand, only the list of Referenceelements within the Manifest is validated.

The committee recommends that within an Object element, SignatureProperties MAY be

used, however the Manifest Element MUST NOT be used as its use could lead to a

situation where the data referred by the references in the Manifest Element changes but

the signature validation is not able to detect this change.


12/26

12

3.5 Enveloped, Enveloping and Detached Signature

Because a single signature can reference/sign multiple resources, a signature may be enveloped,detached, and enveloping at the same time. Furthermore, multiple independent signatures may

coexist within the same XML document.

There are four ways to relate data object to the XML signature:1. Enveloped Signature means that the Signature element is inside the referenced XML

resource. The data object can embed the XML signature within itself.2. Detached Signature on the other hand references a resource that is separate from the

Signature element. the data object resides within the same XML document containing the

XML signature

3. Enveloping Signature references a resource that is contained within the Signatureelement. An instance of the Object element is used to contain the resource. The data

object is embedded within the XML Signature.

4. Detached signature and External Reference the data object resides external to thedocument containing the XML signature, and the carries a reference

to the external data object.

Because the Signature element of an enveloped signature is actually located within the XMLdocument being signed, an enveloped signature transform is defined. This transform removes the

entire Signature element from the digest calculation, so that the signature element is not included

in the digest of the XML resource being signed. Otherwise it would not be possible to calculatethe correct digest, considering that the resource (from which the digest is to be calculated) would

be subject to change when adding the digest to the Signature element.

The committee recommends that XML Signature MAY be of any of three types

Enveloped, Detached and Enveloping Signature.


13/26

13

3.6 Summary of recommendation for XML SIGNATURES

Field Name Components Usage Recommendation1 SignedInfo Canonicalizat

ion Method

The Canonicalization Method is the algorithm

that is used to canonicalize the Signed Info

element before it is digested as part of thesignature operation

It MUST be Exclusive

Canonicalization

Without Comments

Signature

Method

The Signature Method is the algorithm that is

used to convert the canonicalized Signed Info

into the Signature Value

Mandatory

References Each Reference element includes the digest

method and resulting digest value calculated

over the identified data object. It also may

include transformations that produced the input

to the digest operation.

At least one Reference

element is mandatory.

2 SignatureValu

e

None Based64 encoded value of the signature Mandatory

3 KeyInfo MandatoryX509Certific

ate

The certificate to be used for verifying the

associated signature value.

Mandatory

Key Names Identifier for the key used to affix the signature Optional

Key

Agreement

Algorithms

Means to indicate a previously agreed upon key Optional

4 Object Signature

Property

Additional information about the signature like

the timestamp of signing

Optional

3.7 Proposed XML definition, signature creation and verification

methods

See Annexure I


14/26

14

4 CMS Signatures Detailed Examination andRecommendations

This section examines the difference between PKCS#7 and the current CMS standard.

4.1 Difference between PKCS#7 and CMS

4.1.1 References for CMS:

RFC 2315 PKCS #7: Cryptographic Message Syntax Version 1.5

RFC 2630 Cryptographic Message Syntax (CMS) (Obsoleted by RFC 3369)

RFC 3369 Cryptographic Message Syntax (CMS) (Obsoleted by RFC 3852)

RFC 3852 Cryptographic Message Syntax (CMS) (Obsoleted by RFC 5652)RFC 5652 Cryptographic Message Syntax (CMS)

4.1.2 RFC2315

Original PKCS#7 standard, as adopted from the RSA Standard

4.1.3 RFC2630

Accommodated version 1 attribute certificate transfer and algorithm independent key agreement

techniques for key management

4.1.4 RFC 3369

Version 2 attribute certificate transfer is added. The use of version 1 attribute certificates isdeprecated. It accommodates key agreement and symmetric key-encryption key techniques for

key management. Password-based key management is included in the CMS specification, and anextension mechanism to support new key management schemes without further changes to theCMS is specified. Discussion on specific cryptographic algorithms has been moved out to a

different document.

PKCS #7 defines content as:

content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

The CMS defines eContent as:

eContent [0] EXPLICIT OCTET STRING OPTIONAL

This leads to incompatibilities between the CMS and PKCS #7 signedData types when the

encapsulated content is not formatted using the Data type

4.1.5 RFC 3852

Defines extension mechanism to support additional certificate formats and revocation statusinformation formats.


15/26

15

4.1.6 RFC 5652

Adds some clarifications, particularly on the usage of counter-signature unsigned attribute.

4.2 Inference

The differences are not significant so as to render the CMS Signatures invalid as per the IT Act.CMS Signatures allow use of Attribute Certificates. Currently attribute certificates have no legalvalidity in India. However, as the attribute certificate cannot be used for signing (has no public /

private key associated with it), its inclusion in the signature does not render the signature invalid

as per the IT Act. As a result a CMS signature that is otherwise legally valid shall not be treated

as invalid just because it also contains an Attribute Certificate.

4.3 RecommendationsBased on the difference between PKCS#7 signatures (which are valid as per Indian IT Act) and

CMS Signatures (whose legality is being evaluated), the committee recommends as below:

1. Rule 6 of the Information Technology (Certifying Authorities) Rules 2000 framedunder Section 87 be amended to include CMS as legally valid signature format

2. The amended Rule SHALL NOT mention anything about use of AttributeCertificates.

3. The recipient or the relying party of a CMS signature shall be at liberty to ignoreany Attribute Certificate, if present.


16/26

16

5 References

5.1 Normative References

Indian IT Act Information Technology Act, 2000 (No. 21 of 2000)

Indian IT Act Amendment

Information Technology (Amendment) Act, 2008. Bill no. 96-C of 2006

RFC 3275 (Extensible Markup Language) XML-Signature Syntax and Processing, Eastlake

et al., March 2002

XMLDSIG XML Signature Syntax and Processing (Second Edition), W3C Recommendation10 June 2008 (http://www.w3.org/TR/xmldsig-core/)

RFC 5652 Cryptographic Message Syntax (CMS)

5.2 Informative References

RFC 2119 Key words for use in RFCs to Indicate Requirement Levels

XML Extensible Markup Language (XML) 1.0 (Fourth Edition). W3CRecommendation T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen,F.Yergeau. 16 August 2006, edited in place 29 September 2006.

http://www.w3.org/TR/2006/REC-xml-20060816/

XML-C14N Canonical XML. W3C Recommendation. J. Boyer. March 2001.

http://www.w3.org/TR/2001/REC-xml-c14n-20010315 http://www.ietf.org/rfc/rfc3076.txt

XML-C14N11

Canonical XML 1.1. W3C Recommendation. J. Boyer, G. Marcy. 2 May 2008.http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/

XML-exc-C14N

Exclusive XML Canonicalization Version 1.0 W3C Recommendation. J. Boyer,

D. Eastlake 3rd., J. Reagle. July 2002. http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/

XPath XML Path Language (XPath) Version 1.0. W3C Recommendation. J. Clark, S.

DeRose. October 1999. http://www.w3.org/TR/1999/REC-xpath-19991116

XPath Filter-2XML-Signature XPath Filter 2.0. W3C Recommendation. J. Boyer, M. Hughes, J.

Reagle. November 2002. http://www.w3.org/TR/2002/REC-xmldsig-filter2-

20021108/
http://www.w3.org/TR/xmldsig-core/http://www.w3.org/TR/xmldsig-core/http://www.w3.org/TR/xmldsig-core/http://www.w3.org/TR/2001/REC-xml-c14n-20010315http://www.w3.org/TR/2001/REC-xml-c14n-20010315http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/http://www.w3.org/TR/2001/REC-xml-c14n-20010315http://www.w3.org/TR/xmldsig-core/


17/26

17

6 Committee MembersThe following are the list of committee members.

i. Shri Aniruddha Shrotri, CTO & Co-Founder, Tellus

Technologies

Chairman

ii. Ms. Renu Buddhiraja, Director, DIT Member

iii. Shri Tanmoy Prasad, IT Advisory Group, Govt. of

Haryana

Member

iv. Shri Aashish Banati, Scientist F', STQC, New Delhi Member

v. Sh Murali Venkatesan,Sify Technologies Member

vi. Smt.Seema Sharma, Advocate, Delhi High Court Member

vii. Shri Vidhya, TCS-CA Member

viii. Mr Prayag Thale, C-DAC, Mumbai Member

ix. Shri Ruchir Karanjgaokar, (n) Code Solutions-CA Member

x. Shri P. Ramachandran, Office of CCA, DIT Member-Secretary

7 AcknowledgementsThe report acknowledges contribution from the following participants

i. Dr. N Vijayaditya CCA

ii. Mrs Debjani Nag DC(T)

iii. Mrs Harsh Prabha AC(T)

iv. Advocate Vakul Sharma Legal Consultant

v. Gartner Consultant

vi. Mr.Adrian McCullagh Consultant

vii. Mr. Ramanathan eMudhra CA


18/26

18

Annexure I

Proposed rules for XML signature creation and verification

1. The manner of authentication of an electronic record by means of XML Signature. -Authentication of Electronic Records - subject to the provision of this section, any

subscriber may authenticate an electronic record by generating signers XML signature.

Authentication of an electronic record, which contains data as references and

corresponding hashes, is affected by the use of hash algorithm, canonicalization, XML

transformation and asymmetric crypto system to generates an XML Signature which is

unique to the electronic record and the signer's private key.

The XML Signature shall use what is known as "Public Key Cryptography", which

employs an algorithm using two different but mathematical related "keys" one for

creating a XML Signature and another key for verifying the XML Signature, the processtermed as hash function shall be used in both creating and verifying a XML Signature.

2. Creation of XML Signature.-

The signer software constructs reference elements, XML signature element, Signedinfo,

KeyInfo and SignatureValue. To sign an electronic record or any other item ofinformation which is given as reference element(s) in the Signedinfo of XML signature

element, the signer shall perform the following steps.

(i). Reference Generation

a) create reference(s) element(s) with reference to the item of information, xml transform

element(s) (optional), digest algorithms and digest value,

(b) Optionallyapply xml transform(s) to each referenced object in a sequential order.

(c) apply the hash function in the signer's software to each reference elements; the hashfunction shall compute a hash result of standard length which is unique (for all practical

purposes) to each reference element; store the hash result in the reference element;

Note: If the Object element is created, it MUST NOT have a Manifest element. One of

the canonical transformations, viz. the Exclusive Canonicalization "Without Comments"must be mandatorily specified in addition to any other transforms.

(ii). Signature Generation

(a) Create SignedInfo element with SignatureMethod, Canonicalisation Methodand Reference(s).


19/26

19

(b) Apply canonicalisation to Signedinfo and calculate the hash value of canonicalised

SignedInfo using the hashing algorithms implied by the SignatureMethod;

(c) It shall be ensured that the signer is presented the data to be signed in a meaningful

way and that the signer consent is obtained for signing. This is not applicable to

automated signing process where there is no human intervention.

Note: In case of multiple resources being signed together, each resource must be

rendered on the screen. For rendering resources

i. Each referenced XML resource shall be rendered using XSLT. XSLTshall be the last transform done to render the resource on the screen

ii. Each non XML resource shall be rendered using MimeType attributementioned in the object.

This shall ensure that the data being rendered to the user is after other transformations

are performed. The application MAY utilize any other equivalent mechanism to ensure

WYSIWYS.

(d) Transform the hash result into a signature value by encrypting the hash with signer's

private key; the resulting signature shall be unique to both electronic record and private

key used to create it. Perform base64 encoding of the encrypted hash result and use it toform SignatureValue.

(e) Construct the Signature element that includes SignedInfo, items of information,KeyInfo with X509Certificate Element (mandatory) and SignatureValue. The

X509Certificate Element should carry the signer's X509 public key certificate.

3. Verification of XML Signature

Verification of the XML signature shall be accomplished by Signature validation,Reference validation and Certificate Validation. An XML signature shall be treated valid only if

all the three validations as specified below are successful.

(i) Signature validation(a) Compute a new hash result of canonicalised Signedinfo by means of the same hash

function that was used to create the XML Signature

(b) Using the public key contained in the signer's X509 certificate that is included in the

XML signature and the new hash result, the verifier shall check

(i) if the XML Signature was created using the corresponding private key; and

(ii) if the newly computed hash result matches the original result which was transformed

into XML Signature during the signing process. The verification software will confirmthe XML Signature as verified if:


20/26

20

(aa) the signer's private key was used to digitally sign the Signedinfo, which is known

to be the case if the signer's public key was used to verify the signature because thesigner's public key will verify only the XML Signature created with the signer's

private key; and

(bb) the Signedinfo was unaltered, which is known to be the case if the hash resultcomputed by the verifier is identical to the hash result extracted from the XML

Signature during the verification process.

(ii) Reference Validation

(a) Canonicalise the signedinfo element based on the canonicalisation method in theSignedinfo.

(b) For each reference in the Signedinfo

(i) If transformations were applied by the signer, then the verifier software maydereference the URI and execute Transforms provided by the signer in the

Reference element.

(ii) Compute digests of referenced items using the Digestmethod specified in its

reference element and compare generated digests with DigestValue in the

Reference elements

(iii) Compare the generated digest value against DigestValue in the SignedInfo

Reference; if there is any mismatch, validation fails.

(iii) Certificate Validation

(a) Validate the certificate path starting with end entity to trust anchor

(b) Verify the signature on the certificate using the public key from the issuer Certificate.

(c) Verify that the intended time is within the certificate validity.

(d) Verify that certificate is not revoked at the time of signing using CRL or OCSP

6. The standards to be followed for XML signature creation and verification.

The standards associated with the XML signature creation and verification is givenbelow:-


21/26

21

THE PRODUCT STANDARD

XML Signature Standard

RFC 3275 with the following constraint1. Manifest is not permitted inside Object,2. KeyInfo containing X509Certificate element is

mandatory.

3. The Reference Processing shall use the ExclusiveCanonicalization(without comments) in addition to

other transforms.

4. For XML resource, XSLT shall be the last transformdone to enable the rendering of the document on

screen.

5. For rendering of document on the screeni. Each referenced XML resource shall be

implemented using XSLT.

ii. Each non XML resource shall be implementedusing MimeType attribute mentioned in the

object.

XML Namespace RFC 3986

Signature block encoding UTF-8 RFC 3629

Signature Value Encoding Base64 RFC 4648

Reference element Digest SHA1, SHA256

Signature Algorithm SHA1withRSA, SHA256withRSA

Signature blockCanonicalization

Exclusive (without comments), XML-EXC-C14N, RFC 3741

Canonical XML1. Canonical XML 1.0 (omits comments)http://www.w3.org/TR/2001/REC-xml-c14n-20010315

2. Canonical XML 1.1 (omits comments)

http://www.w3.org/2006/12/xml-c14n11

Transform Algorithms

Exclusive (without comments), XML-EXC-C14N, RFC 3741

Canonical XML1. Canonical XML 1.0 (omits comments)

http://www.w3.org/TR/2001/REC-xml-c14n-20010315

2. Canonical XML 1.1 (omits comments)http://www.w3.org/2006/12/xml-c14n11

XSLT -XSL Transforms (XSLT) Version 1.0. W3Chttp://www.w3.org/TR/1999/REC-xslt-19991116

XPathRFC 3653
http://www.w3.org/TR/1999/REC-xslt-19991116http://www.w3.org/TR/1999/REC-xslt-19991116


22/26

22

Signature Type Enveloped or enveloping or detached

Digital Signature Certificate (DER) X.509 V3 issued as per interoperability guidelines

Public Key Algorithms RSA

7 . The basic Syntax of XML Signature and terms used in the rule is given below

(()?

+

(

(KeyName)

(KeyValue)

(RetrievalMethod)(

(X509IssuerSerial)

(X509SKI)

(X509SubjectName)(X509Certificate)

(X509CRL)

(X509IssuerName)(X509SerialNumber)

)

)?()*

Where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*"

denotes zero or more occurrences.

XML is Extensible Markup Language that provides a standard methodology with formal

syntax to identify elements of information, describe the structure of data and also to store data in

an independent manner. With XML, content and presentation are separated. The structure ofwhat the XML Data can contain in a particular context can be described using either XML

Schema or a Document Type Definition. These are stored separately from the XML document

itself and can be used to validate a given XML document for conformance.


23/26

23

XML Schema is a set of pre-defined or user defined keywords and their attributes arranged ina structured manner, which is used for a particular purpose. A schema describes the structure of

an XML document and provides specification of element names that indicates which elements

are allowed in an XML document, and in what combinations. A schema also provides extended

functionality such as data types, inheritance, and presentation rules and default values forattributes.

XML Document is a document with XML logical and physical structure that is used to carrydata elements. The logical structure composed of declarations, elements, comments, character

references, and processing instructions and a physical structure composed of entities, starting

with the root, or document entity.

XML Signature Element is defined by standard XML schema for capturing the result of adigital signature operation applied to arbitrary data in XML format. It is the main element of

XML Signature and it can exist as a standalone document, or can envelop the data object that it

signs. The XML Signature Element has the following child elements in order in which theyappear: ds:SignedInfo, ds:SignatureValue, ds:KeyInfo, ds:Object and has ID attribute of type

(xsd:ID)

Reference Element carries a references to data objects, an optional list of transforms to be

applied prior to digest (XML Transforms), digest method (Digestmethod) and digest value

(DigestValue) value of referenced data objects. It has the following child elements: ds:Transforms, ds: DigestMethod, ds: DigestValue

SignedInfo Element is an electronic record that contains a set of information to be signed forcreating an XML signature. It contains references to the data object and includes the

canonicalization and signature algorithms. The encrypted digest of the canonical form of the

SignedInfo element represents the value of the XML signature. Signedinfo element has the

following child elements: ds: Canonicalization Method, ds:SignatureMethod, ds:Reference.

Canonicalization is a process for converting electronic record that has more than one possiblerepresentation into a "standard", "normal", or canonical form. The variations in representation of

electronic record may be due to the use of different character encodings or insignificant

structural differences. It is necessary that canonicalization is to be performed as part of the XMLsignature creation and verification processes.

XML Transform is an optional ordered list of processing steps applied to the resource's

content before it was digested. Transforms can include operations such as canonicalization,encoding/decoding (including compression/inflation), XSLT, XPath, XML schema validation, or

XInclude.

XML Namespace is identified by a URI reference using the mechanisms described in thespecification RFC3986, which are used in XML documents as element types and attribute


24/26

24

names. Namespace declaration allows XML to use various XML vocabularies without having

name collision.

SignatureValue Element contains the actual value of the digital signature. It has one ID

attribute

SignatureMethod Element specifies the algorithm used for signature generation and thisalgorithm identifies all cryptographic functions involved in the signature generation. It has one

attribute algorithm.

XML Transform Element is an optional ordered list of processing steps applied to the data

objects before it was digested. Transforms include canonicalization, Base64 decoding, XPathfiltering, and Extensible Stylesheet Language Transformations (XSLT).

DigestMethod Element specifies the digest algorithm to be used for the original data object or

transformed if any XML Transforms exists.

DigestValue Element contains the value of the digest.

KeyInfo Element is an element that enables key information to be packaged along with the

XML Signature. It can contain keys, keys names, certificates. It has many child elements such

as: ds: KeyName, ds: KeyValue., ds: RetrievalMethod and ds: X509Data. This report

recommends that KeyInfo MUST be present in the XML Signature and that it MUST haveX50Certificate element.

Object Element is an optional element of XML Signature Element, and typically used forenveloping signature where the data object being signed is included in the XML

Signature Element It can have any child elements and it has tree attributes: ID, MimeType,

and Encoding.

Manifest Element appear as a child of the Object element, provides a structure to carry a list

of Reference element elements similar to that provided by the SignedInfo element, the maindifferent is that in the case of Manifest element the processing model is defy by the application.

SignatureProperties Element provides a way to carry additional information about thesignature, such as a time stamp or a serial number which are defined by application. It contains

one or more Signature Property and has two attributes Id and Target

Enveloped Signature means that the Signature element is inside the referenced XMLresource. The data object can embed the XML signature within itself.

Detached Signature references a resource that is separate from the Signature element. The

data object resides within the same XML document containing the XML signature


25/26

25

Enveloping Signature references a resource that is contained within the Signature element.

An instance of the Object element is used to contain the resource. The data object is embeddedwithin the XML Signature


26/26

Annexure 2

PROPOSED DRAFT

THE SECOND SCHEDULE

[See sub-section (1) of section 3A]

Electronic Signature or Electronic Authentication

Technique and Procedure

SL.No. Description Procedure

(1) (2) (3)

1. XML Signature

.

1) Subject to the provisions of this section any subscriber

may authenticate an electronic record by affixing his XMLsignature.

(2) Authentication of an electronic record by affixing XML

signature shall be effected by the use of hash ALGORITHM,canonicalization, xml transformation and asymmetric cryptosystem to generate an electronic signature record.

(3) By the use of the public key of the subscriber the

electronic record can be verified.(4) the private key and the public key are unique to the

subscriber and constitute a functioning key pair.

Explanation: For the purpose of this schedule,

(a)Canonicalization means a process for convertingelectronic record that has more than one possible

representation into a "standard", "normal", orcanonical form.

(b)XML Transform means an optional ordered list

of processing steps applied to the resource's contentbefore it is hashed.

XML Committee Revised Report

Documents

Transcript of XML Committee Revised Report