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

Ver 2.1 September 2011

SUBMITTED TO
Controller of Certifying Authorities Department of Information Technology Ministry of Communications and Information Technology

Table of Contents
INTRODUCTION .......................................................................................................................................................3 1.1 1.2 1.3 1.4 1.5 2 BACKGROUND ..................................................................................................................................................3 SCOPE AND PURPOSE OF THE REPORT ..............................................................................................................3 XML SIGNATURE OVERVIEW ..........................................................................................................................3 CMS SIGNATURE OVERVIEW ...........................................................................................................................4 ISSUES .............................................................................................................................................................. 4

INFORMATION TECHNOLOGY ACT PROVISION FOR NEW SIGNATURE TYPES ....................5 2.1 DIGITAL AND ELECTRONIC SIGNATURES FROM IT ACT....................................................................................5 2.1.1 Digital Signature (Section 3) .................................................................................................................5 2.1.2 Electronic Signature (Section 3A) .........................................................................................................5 2.2 ADMISSIBILITY OF XML SIGNATURES UNDER IT ACT ....................................................................................6 2.3 CONSIDERING CMS SIGNATURES UNDER IT ACT ............................................................................................ 6

XML SIGNATURES DETAILED EXAMINATION AND RECOMMENDATIONS ............................. 6 3.1 SIGNEDINFO .....................................................................................................................................................8 3.1.1 Canonicalization method .......................................................................................................................8 3.1.2 Signature Method...................................................................................................................................9 3.1.3 Reference ...............................................................................................................................................9 3.2 SIGNATUREVALUE ......................................................................................................................................... 11 3.3 KEYINFO ........................................................................................................................................................ 11 3.4 OBJECT .......................................................................................................................................................... 11 3.5 ENVELOPED, ENVELOPING AND DETACHED SIGNATURE ................................................................................ 12 3.6 SUMMARY OF RECOMMENDATION FOR XML SIGNATURES........................................................................ 13 3.7 PROPOSED XML DEFINITION, SIGNATURE CREATION AND VERIFICATION METHODS ...................................... 13

CMS SIGNATURES DETAILED EXAMINATION AND RECOMMENDATIONS ........................... 14 4.1 DIFFERENCE BETWEEN PKCS#7 AND CMS ................................................................................................... 14 4.1.1 References for CMS: ............................................................................................................................ 14 4.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 ..................................................................................................................................................... 15 4.3 RECOMMENDATIONS ...................................................................................................................................... 15

REFERENCES ................................................................................................................................................. 16 5.1 5.2 NORMATIVE REFERENCES .............................................................................................................................. 16 INFORMATIVE REFERENCES ........................................................................................................................... 16

6 7

COMMITTEE MEMBERS ............................................................................................................................ 17 ACKNOWLEDGEMENTS ............................................................................................................................. 17

ANNEXURE I ............................................................................................................................................................ 18 PROPOSED RULES FOR XML SIGNATURE CREATION AND VERIFICATION ...................................... 18 ANNEXURE 2 ........................................................................................................................................................... 26

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 under the 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 and W3C (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 validity were discussed. Committee also consulted with national and international experts and examined applicable international best practices in the area. This report summarizes the conclusions of the meetings 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 as Internet 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 Signatures for 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 as per IT Act. XML Signature defines how to apply well established hashing and cryptographic algorithms 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, where each 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 indirect signatures. 3

1.4 CMS Signature Overview

Cryptographic Message Syntax (CMS) is an Internet Engineering Task Force (IETF) standard that 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 Laboratories Technical 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, such as 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 of which 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 or Digital Signature under Section 3 of IT Act. Whether XML and CMS signing follows "What You See is What You Sign" principle does 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 under section 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 violate the principle of reliability of the signatures as laid out by the IT Act and how should these be addressed

2 Information Technology Act Provision for New Signature Types

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 grey background. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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 the IT 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 record into another electronic record. Explanation For the purposes of this sub-section, "hash function" means an algorithm mapping or translation of one sequence of bits into another, generally smaller, set known as "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 result produced 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 electronic record. (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 subsection (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;

(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 no other 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 electronic signature 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 the section 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 XML Signatures as Electronic Signature.

2.3 Considering CMS Signatures under IT Act

IT 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 and Recommendations

This section examines the constituents of XML Signatures in details and gives recommendations of 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 from or 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. 6

<Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI?> (<Transforms>)? <DigestMethod> <DigestValue> </Reference>+ </SignedInfo> <SignatureValue> (<KeyInfo> (KeyName) (KeyValue) (RetrievalMethod) (<X509Data> (X509IssuerSerial) (X509SKI) (X509SubjectName) (X509Certificate) (X509CRL) (X509IssuerName) (X509SerialNumber) <x509Data>) </Keyinfo>)? (<Object ID?>)* </Signature>

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 are mandatory. 1. The SignedInfo sub-document specifies the data to be signed. This is a mandatory element 2. SignatureValue yields the digital signature itself. This is also a mandatory element 3. 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 number of 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.

3.1 SignedInfo
The SignedInfo element is the one that is actually signed. It contains one or more Reference elements, 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 canonical form 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 or insignificant structural differences. Canonicalization methods define a normal form, that is, the canonical form, into which logically equivalent documents, can be converted to obtain the same physical representation. There are two main canonicalization methods, Canonical XML and Exclusive XML Canonicalization In order to be able to verify the signature of an XML resource that has had its representation changed, it is essential that canonicalization is performed as part of the XML signature creation and verification processes

Canonical XML and Exclusive XML Canonicalization Canonicalization 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 different representations for equivalence, to count the number of distinct data structures, to improve the efficiency 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 the canonicalised 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 has other 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 to ensure 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

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 is applied 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 in both 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 the rendered 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 signature standard itself does not declare any specific mathematical signature functions. The commonly used 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 Transform elements. 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 9

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.1 URI attribute

The 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 is also verified as a part of signature verification process

3.1.3.2 DigestMethod
The last element within the Reference element is the DigestMethod element, used for specifying the 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.3 DigestValue
This is the digest value of the data referenced by the URI and digested using the DigestMethod described above.

3.1.3.4 Transformation
Apart from canonicalization, several other transformations may be applied to a resource. These include 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 legal disputes. 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. It requires 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.

10

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 transformations are 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. Information about 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 be provided 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 packet can 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 properties of 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 Reference elements 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.

11

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 Signature element. 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 the document containing the XML signature, and the <Signature element> carries a reference to the external data object. Because the Signature element of an enveloped signature is actually located within the XML document 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 calculate the 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.

12

3.6 Summary of recommendation for XML SIGNATURES

1

Field Name SignedInfo

Components Canonicalizat ion Method

Signature Method References

2 3

SignatureValu e KeyInfo

None

Usage The Canonicalization Method is the algorithm that is used to canonicalize the Signed Info element before it is digested as part of the signature operation The Signature Method is the algorithm that is used to convert the canonicalized Signed Info into the Signature Value 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. Based64 encoded value of the signature

Recommendation It MUST be Exclusive Canonicalization Without Comments Mandatory

At least one Reference element is mandatory.

Mandatory

Object

X509Certific ate Key Names Key Agreement Algorithms Signature Property

Mandatory The certificate to be used for verifying the Mandatory associated signature value. Identifier for the key used to affix the signature Optional Means to indicate a previously agreed upon key Optional

Additional information about the signature like Optional the timestamp of signing

3.7 Proposed XML definition, signature creation and verification methods

See Annexure I

13

4 CMS Signatures Detailed Examination and Recommendations

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 RFC 2630 RFC 3369 RFC 3852 RFC 5652 PKCS #7: Cryptographic Message Syntax Version 1.5 Cryptographic Message Syntax (CMS) (Obsoleted by RFC 3369) Cryptographic Message Syntax (CMS) (Obsoleted by RFC 3852) Cryptographic Message Syntax (CMS) (Obsoleted by 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 is deprecated. It accommodates key agreement and symmetric key-encryption key techniques for key management. Password-based key management is included in the CMS specification, and an extension mechanism to support new key management schemes without further changes to the CMS 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 status information formats. 14

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 legal validity 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 Recommendations
Based 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 framed under Section 87 be amended to include CMS as legally valid signature format 2. The amended Rule SHALL NOT mention anything about use of Attribute Certificates. 3. The recipient or the relying party of a CMS signature shall be at liberty to ignore any Attribute Certificate, if present.

15

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 Recommendation 10 June 2008 (http://www.w3.org/TR/xmldsig-core/) RFC 5652 Cryptographic Message Syntax (CMS)

5.2 Informative References

RFC 2119 XML Key words for use in RFCs to Indicate Requirement Levels Extensible Markup Language (XML) 1.0 (Fourth Edition). W3C Recommendation 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-xmlexc-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-2 XML-Signature XPath Filter 2.0. W3C Recommendation. J. Boyer, M. Hughes, J. Reagle. November 2002. http://www.w3.org/TR/2002/REC-xmldsig-filter220021108/

16

Committee Members
i. Shri Aniruddha Shrotri, CTO & Co-Founder, Tellus Technologies Chairman

The following are the list of committee members.

ii. Ms. Renu Buddhiraja, Director, DIT iii. Shri Tanmoy Prasad, IT Advisory Group, Govt. of Haryana iv. Shri Aashish Banati, Scientist F', STQC, New Delhi v. Sh Murali Venkatesan, Sify Technologies vi. Smt.Seema Sharma, Advocate, Delhi High Court vii. Shri Vidhya, TCS-CA viii. Mr Prayag Thale, C-DAC, Mumbai ix. Shri Ruchir Karanjgaokar, (n) Code Solutions-CA x. Shri P. Ramachandran, Office of CCA, DIT

Member Member

Member Member Member Member Member Member Member-Secretary

Acknowledgements
i. Dr. N Vijayaditya CCA DC(T) AC(T) Legal Consultant Consultant Consultant eMudhra CA

The report acknowledges contribution from the following participants

ii. Mrs Debjani Nag iii. Mrs Harsh Prabha iv. Advocate Vakul Sharma v. Gartner vi. Mr.Adrian McCullagh vii. Mr. Ramanathan

17

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 process termed 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 of information 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) Optionally apply 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 hash function 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 Method and Reference(s).

18

(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. XSLT shall be the last transform done to render the resource on the screen ii. Each non XML resource shall be rendered using MimeType attribute mentioned 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 to form 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 confirm the XML Signature as verified if:

19

(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 the signer'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 result computed 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 the Signedinfo. (b) For each reference in the Signedinfo (i) If transformations were applied by the signer, then the verifier software may dereference 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 given below:-

20

THE PRODUCT

XML Signature Standard

XML Namespace Signature block encoding Signature Value Encoding Reference element Digest Signature Algorithm

STANDARD RFC 3275 with the following constraint 1. Manifest is not permitted inside Object, 2. KeyInfo containing X509Certificate element is mandatory. 3. The Reference Processing shall use the Exclusive Canonicalization(without comments) in addition to other transforms. 4. For XML resource, XSLT shall be the last transform done to enable the rendering of the document on screen. 5. For rendering of document on the screen i. Each referenced XML resource shall be implemented using XSLT. ii. Each non XML resource shall be implemented using MimeType attribute mentioned in the object. RFC 3986 UTF-8 RFC 3629 Base64 RFC 4648 SHA1, SHA256 SHA1withRSA, SHA256withRSA Exclusive (without comments), XML-EXC-C14N, RFC 3741 Canonical XML 1. 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 Exclusive (without comments), XML-EXC-C14N, RFC 3741 Canonical XML 1. 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. W3C http://www.w3.org/TR/1999/REC-xslt-19991116 XPath RFC 3653

Signature block Canonicalization

Transform Algorithms

21

Signature Type Digital Signature Certificate Public Key Algorithms

Enveloped or enveloping or detached (DER) X.509 V3 issued as per interoperability guidelines RSA

7 . The basic Syntax of XML Signature and terms used in the rule is given below <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI?> (<Transforms>)? <DigestMethod> <DigestValue> </Reference>+ </SignedInfo> <SignatureValue> (<KeyInfo> (KeyName) (KeyValue) (RetrievalMethod) (<X509Data> (X509IssuerSerial) (X509SKI) (X509SubjectName) (X509Certificate) (X509CRL) (X509IssuerName) (X509SerialNumber) <x509Data>) </Keyinfo>)? (<Object ID?>)* </Signature> 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 of what 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. 22

XML Schema is a set of pre-defined or user defined keywords and their attributes arranged in a 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 for attributes. XML Document is a document with XML logical and physical structure that is used to carry data 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 a digital 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 they appear: 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 for creating 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 possible representation 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 XML signature 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 the specification RFC3986, which are used in XML documents as element types and attribute

23

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 this algorithm 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, XPath filtering, 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 have X50Certificate element. Object Element is an optional element of XML Signature Element, and typically used for enveloping 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 main different 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 the signature, 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 XML resource. 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

24

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 embedded within the XML Signature

25

Annexure 2 PROPOSED DRAFT THE SECOND SCHEDULE [See sub-section (1) of section 3A] Electronic Signature or Electronic Authentication Technique and Procedure

SL.No. (1) 1.

Description (2) XML Signature

Procedure (3)

1) Subject to the provisions of this section any subscriber may authenticate an electronic record by affixing his XML signature. (2) Authentication of an electronic record by affixing XML signature shall be effected by the use of hash ALGORITHM, canonicalization, xml transformation and asymmetric crypto system 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 converting electronic record that has more than one possible representation into a "standard", "normal", or canonical form. (b)XML Transform means an optional ordered list of processing steps applied to the resource's content before it is hashed.

26