XML Committee Revised Report - Free Download PDF Ebook

Revised Report of the Committee on New PKI based Digital / Electronic Signature SchemesVer 2.1 September 2011 SUBMITTED TO Controller of Certifying Authorities Department of Information Technology Ministry of Communications and Information Technology 1 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 3 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 4 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 5 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 2 IETF and W3C (W3C XML Signature. A committee was setup by CCA to examine this via an Office Memorandum dated 19th July 2010. A single XML signature may cover several resources. XML Signature defines how to apply well established hashing and cryptographic algorithms to XML documents. Several PKI based new signatures schemes are available. therefore are needed to be conducted before adoption of these signatures under IT ACT. a part of an XML document. This includes a standardized way to represent signatures. 1. where each resource may be an XML document. and non-repudiation. the terms and definition used have been taken from the sources such as Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C). PKCS#7 based signatures are the only valid signatures as per standards under the IT Act. authentication. XML signature is independent of whether the signed resource is an XML resource or not. The CMS based signatures are suitable for Long term archival and Time Stamping. 3 . Several meetings of the committee were held where different issues related to the legal validity were discussed.1 Background The Information Technology Act came into effect in 2000 and was subsequently modified in 2008. The XML signatures are proposed to be used in e-governance application. If not found to fulfill the requirements. A detailed technical evaluation of these signatures. 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. which include CMS and XML signatures.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. or a binary resource. This report summarizes the conclusions of the meetings and work done thereafter. and information about the associated key(s). The details of the same are available in section 5. Throughout the report.Introduction 1. At present. has developed an XML compliant syntax for representing XML signatures. Committee also consulted with national and international experts and examined applicable international best practices in the area. 2003). XML Signature uses same hashing and cryptographic algorithms as used in Digital Signature as per IT Act. The report contains specific recommendations of the committee to bring the XML Signatures and CMS Signatures under the ambit of the IT Act. 1.3 XML Signature Overview XML Signature is used for ensuring message integrity. Also the Committee examined CMS Signatures with respect to same aspects. 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. as described by PKCS#7 is the only one type of signature currently approved by IT Act 2000. Digital Signature. With this.5. authenticate. standard asymmetric technique is used for Digital signature. • make use of recursive format The PKCS#7 permits recursion. some of which are backward compatible but some are not.4 CMS Signature Overview Cryptographic Message Syntax (CMS) is an Internet Engineering Task Force (IETF) standard that is used to digitally sign. or one party can sign some previously enveloped digital data. It supports digital signatures and encryption. The CMS is derived from PKCS#7 version 1. or encrypt arbitrary message content. 1. PKCS#7. RFC 5652 has added many features to the original PKCS#7. It also provides for other attributes such as counter signatures to be associated with a signature.  What features of XML Signatures are to be considered for reliability and acceptance under Section 3A of IT Act. to be authenticated along with the content of a message. timestamps and other information.1. if not should it be amended to mandate it. the IETF has taken responsibility for the development and maintenance of the CMS. It also allows arbitrary attributes. describes encapsulation syntax for data protection. 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 4 .  Whether XML and CMS signing follows "What You See is What You Sign" principle – does the IT Act explicitly mandate it. which was originally published as an RSA Laboratories Technical Note in November 1993. CRLs. the precursor of CMS.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. It can • host multiple signatures (hierarchical or parallel) • can carry certificates. such as signing time. 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. Since that time. The current CMS standard. one envelope can be nested inside another. for example. (3) Any person by the use of a public key of the subscriber can verify the electronic record. "MUST NOT". "RECOMMENDED". the authenticator and to no other person. "SHOULD NOT". 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. but subject to the provisions of subsection (2).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. and (b) may be specified in the Second Schedule. within the context in which they are used. "REQUIRED". (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. The recommendations are hi-lighted with a box and a grey background. as the case may be. "MAY". linked to the signatory or. "SHALL". a subscriber may authenticate any electronic record by such electronic signature or electronic authentication technique which — (a) is considered reliable. (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.1. "SHALL NOT".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. (b) that two electronic records can produce the same hash result using the algorithm. generally smaller.2 Electronic Signature (Section 3A) 3A (1) Notwithstanding anything contained in section 3. 5 . "SHOULD". Explanation — For the purposes of this sub-section. "hash function" means an algorithm mapping or translation of one sequence of bits into another. and "OPTIONAL" in this report are to be interpreted as described in RFC2119. (4) The private key and the public key are unique to the subscriber and constitute a functioning key pair. The key words "MUST". 2. 2.1.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. 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. 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). Committee is of the opinion that rules can be formulated under section 3A to add XML Signatures as Electronic Signature. 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. 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. Therefore. 6 .. The differences between PKCS#7 and CMS signatures are not very significant. under the control of the signatory or. (d) any alteration to the information made after its authentication by electronic signature is detectable.3 Considering CMS Signatures under IT Act IT Act 2000. as the case may be. 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. This section records all the recommendations of this committee that deviate from or further qualify the standard definition given in RFC 3275. Eastlake et al. the authenticator and of no other person. The Rules do not directly cover CMS signatures. and (e) it fulfils such other conditions which may be prescribed 2. Normative definition of XML Signature can be found in RFC 3275 – ―(Extensible Markup Language) XML-Signature Syntax and Processing. (c) any alteration to the electronic signature made after affixing such signature is detectable.(b) the signature creation data or the authentication data were. March 2002‖. at the time of signing. The following describes the structure of an XML signature. recognizes only PKCS#7 signatures as valid signatures. and "*" denotes zero or more occurrences Signature Composition A XML signature itself is a XML document. two of which are mandatory. the committee recommends that KeyInfo MUST be used in XML Signature. ―SignatureValue‖ yields the digital signature itself. 7 . The KeyInfo will be used for storing the X. 4. Use of this element is up to the application. This list may just have any number of elements. The Object element is still optional and can be used for storing values such as signature time. 1. "+" denotes one or more occurrences. Accordingly. Apart from the two mandatory elements. It consists of four elements.509 certificate of the signer. The ―SignedInfo‖ sub-document specifies the data to be signed. An optional ―KeyInfo‖ node contains information about the key used to sign the document. This is a mandatory element 2. This is also a mandatory element 3.<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. or the list may be empty. A list of ―Object‖ nodes completes the document. X509 Certificate MUST be used inside KeyInfo element. 3. that is. the canonical form. The Signature algorithm typically includes a digest algorithm and an asymmetric encryption algorithm. to improve the efficiency of various algorithms by eliminating repeated calculations.1 Canonicalization method Canonicalization is one possible transform that may be applied to an XML resource before calculating the digest. Canonicalization methods define a normal form. Exclusive Canonicalization establishes the name spaces actually used and just includes those. The need for XML canonicalization is because of the fact that two logically equivalent XML resources may differ in physical representation. The Canonicalization algorithm is used to convert the SignedInfo element into a standard form before it is signed or verified. 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. can be converted to obtain the same physical representation. to count the number of distinct data structures.1 SignedInfo The SignedInfo element is the one that is actually signed. This can be done to compare different representations for equivalence. If a signed XML document is put into another XML document that has other declarations. Inclusive XML canonicalization guarantees that all declarations that might be used will be unambiguously specified. and the signature algorithm identifier. 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 8 . "normal".with or without comments. into which logically equivalent documents. they include and exclude the comments in the canonicalised forms respectively. 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". As the name implies. or to make it possible to impose a meaningful sorting order. the canonicalization algorithm identifier. There are two main canonicalization methods. Canonical XML and Exclusive XML Canonicalization are two variations of canonicalisation (though suitable for different contexts) and each of these has two further variants -. It contains one or more Reference elements. Inclusive Canonicalization will copy those and the signature will become invalid. or canonical form. 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. Such variations in physical representation may for instance be due to the use of different character encodings or insignificant structural differences.1. Comments are useful only for someone inspecting the XML rather than for someone who is looking at the rendered view of the XML document. comments inherently do not form a part of the data. can be meaningless if a strange and badly understood Canonicalization Method is used. The commonly used signature methods are DSA with SHA1.2 Signature Method The ―SignatureMethod‖ gives the algorithms used to obtain the signature. The URL defines how the resource can be obtained. in which case canonicalization applies to the specific data being signed for a given Reference. The XML signature standard itself does not declare any specific mathematical signature functions.3 Reference A URI identifies a resource either by location. Since the Interoperability guidelines for digital signature only recommend RSA with SHA256. A Signature which appears to authenticate the desired data with the desired key. the committee recommends that the signature method MUST be RSA with SHA256 for XML signature. a hash value (DigestValue). or a name. The canonicalization algorithms are used with XML Signatures in two ways. Each Reference element includes a Uniform Resource Identifier (URI). 3. More often than not. The DigestValue contains a hash value after applying the digest 9 . 3.the same document. or both. and an optional list of Transform elements. One anticipated use of this capability is to allow intermediaries to add additional signatures or XML wrappers. Cannonicalization is requirement for XML signature.1. RSA with SHA1 or HMAC13 with SHA1. To avoid namespace problems. Exclusive XML Canonicalization should be used in both places As for whether to include comments in canonicalization. It can point to an element inside an XML message. or resources located in the Internet. They can also be applied as a Transform within a Reference.1. an element inside the Signature element such as Object or KeyInfo. The committee recommends that canonicalization MUST be used and it MUST be Exclusive Canonicalization Without Comments. the digest algorithm identifier (DigestMethod). any change to the comment should not invalidate the signature. most of us use URIs that defines a location to a resource. The URI is a pointer that identifies the data to be signed. A URL is a specialization of URI that defines the network location of a specific resource. DigestMethod. They can be specified as the Canonicalization Method for the Signature (in which case canonicalization is applied specifically to the SignedInfo element). Therefore. and SignatureMethod. and the signer is not really signing on the comments in the XML. 1.3. URL can point to data in the same document or different document. the committee recommends that the DigestMethod MUST be SHA256 or higher as notified under the IT Act. it actually doesn't.3. 10 . This issue is particularly crucial in the case of legal disputes. Furthermore. However.1. XML signature supports selective signature processing. 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.1. 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.3.2 DigestMethod The last element within the Reference element is the DigestMethod element. In the case of XPath transform.4 Transformation Apart from canonicalization. and Extensible Stylesheet Language Transformations (XSLT).1 URI attribute The URI attribute identifies a data object using a URI-Reference. The use of XPath or Xpointer allows inclusion or exclusion of portions of content from the signature. The only digest algorithm required to be supported is SHA-256. A related issue is that of What You See Is What You Sign (or WYSIWYS). 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. XSLT transform also may cause nothing to be selected for signing.3 DigestValue This is the digest value of the data referenced by the URI and digested using the DigestMethod described above. 3. This is a fundamental guiding principle behind the Indian IT Act. If the Transform element exists. used for specifying the digest algorithm being used. it is possible that it evaluates to zero or false for every node.1. 3.algorithm to the data pointed by its URI. 3. though it is not spelt out explicitly. In any case the data pointed by it is hashed. it includes an ordered list of transform algorithms that are applied to the data before being digested. These include Base64 decoding.3. XPath filtering. so it ends up selecting nothing. So even though the signature seems to sign some data. The hash is also verified as a part of signature verification process 3. several other transformations may be applied to a resource. which may be used to provide information about the key to be used for verifying the signature. The Object element may contain SignatureProperties or Manifest or any arbitrary data. 3.509 certificate. Information about the owner of the digital key etc. 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. and/or by including (or referencing) an X.3 KeyInfo The KeyInfo node holds information about the key used to create the signature. by including the raw public key itself. however. On the other hand.The committee recommends that in case of a human user signing XML data (as opposed to an application signing the data without human interaction). This information may be provided by identifying the key by name..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. The SignatureProperty identifies properties of the signature itself such as the date/time when the signature was created. the RetrievalMethod element may be used to reference KeyInfo information at another location (i. then XSLT shall be the last of the transforms. can be stored here. The Manifest element includes one or more Reference elements same as the Reference element within the SignedInfo. though KeyInfo is optional according to XML Signature schema. 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. The rendering of non XML-resource shall be implemented using MimeType attribute mentioned in the object. They are semantically equal. This shall ensure that the data being rendered to the user is after the specified transformations are performed. The committee recommends that within an Object element. 11 .4 Object The Signature may contain zero or more Object elements. within another KeyInfo element). The committee recommends use of public-private key cryptographic technique in combination with X. Furthermore. each Reference in the SignedInfo has to be validated in order to consider a valid signature.e. Using the PGPData element. Furthermore.509v3 digital signature certificate provided by a licensed CA in forming XML Signature. SignatureProperties MAY be used. a PGP key packet can also be included. only the list of Reference elements within the Manifest is validated. the committee recommends that KeyInfo element with the X509Certificate option MUST be present in the XMLSignature 3. Detached signature and External Reference the data object resides external to the document containing the XML signature. and enveloping at the same time. Furthermore. Because the Signature element of an enveloped signature is actually located within the XML document being signed.5 Enveloped. and the <Signature element> carries a reference to the external data object. Otherwise it would not be possible to calculate the correct digest. Enveloping Signature references a resource that is contained within the Signature element. 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. 4. This transform removes the entire Signature element from the digest calculation.3. multiple independent signatures may coexist within the same XML document. 2. 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 data object is embedded within the XML Signature. Detached and Enveloping Signature. Enveloped Signature means that the Signature element is inside the referenced XML resource. The data object can embed the XML signature within itself. an enveloped signature transform is defined. so that the signature element is not included in the digest of the XML resource being signed. The committee recommends that XML Signature MAY be of any of three types – Enveloped. Enveloping and Detached Signature Because a single signature can reference/sign multiple resources. An instance of the Object element is used to contain the resource. There are four ways to relate data object to the XML signature: 1. detached. a signature may be enveloped. 12 . 3.7 Proposed XML definition. It also may include transformations that produced the input to the digest operation. signature creation and verification methods See Annexure I 13 . Based64 encoded value of the signature Recommendation It MUST be Exclusive Canonicalization Without Comments Mandatory At least one Reference element is mandatory. 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.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. Mandatory 4 Object X509Certific ate Key Names Key Agreement Algorithms Signature Property Mandatory The certificate to be used for verifying the Mandatory associated signature value. 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. It accommodates key agreement and symmetric key-encryption key techniques for key management. as adopted from the RSA Standard 4.1.1 References for CMS: RFC 2315 RFC 2630 RFC 3369 RFC 3852 RFC 5652 PKCS #7: Cryptographic Message Syntax Version 1.2 RFC2315 Original PKCS#7 standard.3 RFC2630 Accommodated version 1 attribute certificate transfer and algorithm independent key agreement techniques for key management 4.1. 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. The use of version 1 attribute certificates is deprecated.4 RFC 3369 Version 2 attribute certificate transfer is added.5 RFC 3852 Defines extension mechanism to support additional certificate formats and revocation status information formats.1.1. 14 . Password-based key management is included in the CMS specification.1 Difference between PKCS#7 and CMS 4.4 CMS Signatures – Detailed Examination and Recommendations This section examines the difference between PKCS#7 and the current CMS standard.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. 4. 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). as the attribute certificate cannot be used for signing (has no public / private key associated with it). The amended Rule SHALL NOT mention anything about use of Attribute Certificates. 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. its inclusion in the signature does not render the signature invalid as per the IT Act. 4. if present.2 Inference The differences are not significant so as to render the CMS Signatures invalid as per the IT Act.1. Currently attribute certificates have no legal validity in India. However.6 RFC 5652 Adds some clarifications. the committee recommends as below: 1. CMS Signatures allow use of Attribute Certificates. 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. 3. The recipient or the relying party of a CMS signature shall be at liberty to ignore any Attribute Certificate. 4. 15 . particularly on the usage of counter-signature unsigned attribute. Boyer. D. 2000 (No. G. 16 August 2006. M. Bill no. Clark. http://www. DeRose. M.0 (Fourth Edition). Hughes. 2008. Eastlake 3rd.1 Normative References Indian IT Act Information Technology Act. W3C Recommendation. J. March 2001.org/TR/2001/REC-xml-c14n-20010315 http://www. J.org/TR/2008/REC-xml-c14n11-20080502/ XML-exc-C14N Exclusive XML Canonicalization Version 1. Sperberg-McQueen.2 Informative References RFC 2119 XML Key words for use in RFCs to Indicate Requirement Levels Extensible Markup Language (XML) 1. http://www. Bray.w3. Boyer.w3. W3C Recommendation. J. W3C Recommendation 10 June 2008 (http://www.org/TR/xmldsig-core/) RFC 5652 Cryptographic Message Syntax (CMS) 5. S. C.Yergeau. http://www.0. November 2002.w3. Maler. July 2002.txt XML-C14N11 Canonical XML 1. 21 of 2000) Indian IT Act Amendment Information Technology (Amendment) Act.w3. http://www. 96-C of 2006 RFC 3275 (Extensible Markup Language) XML-Signature Syntax and Processing.w3. J. October 1999. 2 May 2008..ietf. W3C Recommendation. J. W3C Recommendation T. E.org/TR/2002/REC-xmlexc-c14n-20020718/ XPath XML Path Language (XPath) Version 1.0 W3C Recommendation.0. Reagle.org/TR/2006/REC-xml-20060816/ XML-C14N Canonical XML. W3C Recommendation.w3.. Boyer. F.org/TR/1999/REC-xpath-19991116 XPath Filter-2 XML-Signature XPath Filter 2. Reagle. Boyer. http://www.w3. Paoli.org/TR/2002/REC-xmldsig-filter220021108/ 16 . March 2002 XMLDSIG XML Signature Syntax and Processing (Second Edition). http://www. Marcy. J. Eastlake et al. edited in place 29 September 2006. J. J.1.org/rfc/rfc3076.5 References 5. Renu Buddhiraja. Mrs Harsh Prabha iv. of Haryana iv. Ms. Ramachandran. Advocate Vakul Sharma v. Mr. Shri Aashish Banati. Delhi High Court vii. IT Advisory Group. Scientist ‗F'. DIT Member Member Member Member Member Member Member Member Member-Secretary 7 Acknowledgements i.6 Committee Members i. New Delhi v. Dr. Mrs Debjani Nag iii. Shri P. Mr. Mr Prayag Thale. Ramanathan 17 . STQC. Director. Smt. Sify Technologies vi. Shri Tanmoy Prasad. Gartner vi. Shri Ruchir Karanjgaokar. Tellus Technologies Chairman The following are the list of committee members. CTO & Co-Founder.Adrian McCullagh vii. Mumbai ix. N Vijayaditya CCA DC(T) AC(T) Legal Consultant Consultant Consultant eMudhra CA The report acknowledges contribution from the following participants ii. ii. C-DAC. TCS-CA viii. Shri Aniruddha Shrotri. Office of CCA.Seema Sharma. Shri Vidhya. DIT iii. Advocate. (n) Code Solutions-CA x. Govt. Sh Murali Venkatesan. the hash function shall compute a hash result of standard length which is unique (for all practical purposes) to each reference element. KeyInfo and SignatureValue. Canonicalisation Method and Reference(s). 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 signer software constructs reference elements. Creation of XML Signature. the Exclusive Canonicalization "Without Comments" must be mandatorily specified in addition to any other transforms. Signedinfo. One of the canonical transformations. Authentication of an electronic record. (ii). Authentication of Electronic Records . any subscriber may authenticate an electronic record by generating signers XML signature. (i). 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. digest algorithms and digest value. the process termed as hash function shall be used in both creating and verifying a XML Signature. The XML Signature shall use what is known as "Public Key Cryptography". viz. (b) Optionally apply xml transform(s) to each referenced object in a sequential order. 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 manner of authentication of an electronic record by means of XML Signature. it MUST NOT have a Manifest element. 18 . which contains data as references and corresponding hashes. Note: If the Object element is created. 2.Annexure I Proposed rules for XML signature creation and verification 1. (c) apply the hash function in the signer's software to each reference elements.subject to the provision of this section. xml transform element(s) (optional). is affected by the use of hash algorithm. store the hash result in the reference element. the signer shall perform the following steps. Reference Generation a) create reference(s) element(s) with reference to the item of information. XML signature element. Signature Generation (a) Create SignedInfo element with SignatureMethod. canonicalization. KeyInfo with X509Certificate Element (mandatory) and SignatureValue. (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. Verification of XML Signature Verification of the XML signature shall be accomplished by Signature validation. Perform base64 encoding of the encrypted hash result and use it to form SignatureValue. items of information. Reference validation and Certificate Validation. An XML signature shall be treated valid only if all the three validations as specified below are successful.(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. Each non XML resource shall be rendered using MimeType attribute mentioned in the object. Note: In case of multiple resources being signed together. For rendering resources i. The verification software will confirm the XML Signature as verified if: 19 . The X509Certificate Element should carry the signer's X509 public key certificate. (e) Construct the Signature element that includes SignedInfo. Each referenced XML resource shall be rendered using XSLT. This shall ensure that the data being rendered to the user is after other transformations are performed. each resource must be rendered on the screen. 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. (d) Transform the hash result into a signature value by encrypting the hash with signer's private key. 3. the resulting signature shall be unique to both electronic record and private key used to create it. This is not applicable to automated signing process where there is no human intervention. The application MAY utilize any other equivalent mechanism to ensure WYSIWYS. XSLT shall be the last transform done to render the resource on the screen ii. (d) Verify that certificate is not revoked at the time of signing using CRL or OCSP 6. then the verifier software may dereference the URI and execute Transforms provided by the signer in the Reference element. and (bb) the Signedinfo was unaltered. (ii) Reference Validation (a) Canonicalise the signedinfo element based on the canonicalisation method in the Signedinfo. (c) Verify that the intended time is within the certificate validity. (b) For each reference in the Signedinfo (i) If transformations were applied by the signer. if there is any mismatch. 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. (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. 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. validation fails. The standards associated with the XML signature creation and verification is given below:- 20 .(aa) the signer's private key was used to digitally sign the Signedinfo. (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. The standards to be followed for XML signature creation and verification. org/2006/12/xml-c14n11 Exclusive (without comments).1 (omits comments) http://www. W3C http://www. RFC 3741 Canonical XML 1. 3. Canonical XML 1.w3. XML-EXC-C14N. For XML resource. RFC 3741 Canonical XML 1. RFC 3986 UTF-8 RFC 3629 Base64 RFC 4648 SHA1.XSL Transforms (XSLT) Version 1. XSLT shall be the last transform done to enable the rendering of the document on screen.w3.w3. Canonical XML 1.0 (omits comments) http://www. KeyInfo containing X509Certificate element is mandatory. SHA256 SHA1withRSA. ii. Canonical XML 1. Canonical XML 1. 5.1 (omits comments) http://www.0. Manifest is not permitted inside Object. SHA256withRSA Exclusive (without comments).0 (omits comments) http://www. For rendering of document on the screen i.w3.org/TR/2001/REC-xml-c14n-20010315 2. The Reference Processing shall use the Exclusive Canonicalization(without comments) in addition to other transforms. XML-EXC-C14N.org/2006/12/xml-c14n11 XSLT .org/TR/2001/REC-xml-c14n-20010315 2. Each referenced XML resource shall be implemented using XSLT.org/TR/1999/REC-xslt-19991116 XPath – RFC 3653 Signature block Canonicalization Transform Algorithms 21 . 4. 2. Each non XML resource shall be implemented using MimeType attribute mentioned in the object.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.w3. ‖ ―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.Signature Type Digital Signature Certificate Public Key Algorithms Enveloped or enveloping or detached (DER) X. content and presentation are separated. and "*" denotes zero or more occurrences. 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.509 V3 issued as per interoperability guidelines RSA 7 . 22 . With XML. "+" denotes one or more occurrences. 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. ds:KeyInfo. inheritance. XSLT. Signedinfo element has the following child elements: ds: Canonicalization Method. or document entity. which is used for a particular purpose. an optional list of transforms to be applied prior to digest (XML Transforms). XPath. character references. It is necessary that canonicalization is to be performed as part of the XML signature creation and verification processes. It contains references to the data object and includes the canonicalization and signature algorithms. encoding/decoding (including compression/inflation). A schema also provides extended functionality such as data types. and in what combinations. The logical structure composed of declarations. starting with the root. or canonical form. ―Canonicalization‖ is a process for converting electronic record that has more than one possible representation into a "standard". ds: DigestValue ―SignedInfo Element‖ is an electronic record that contains a set of information to be signed for creating an XML signature. ―XML Namespace‖ is identified by a URI reference using the mechanisms described in the specification RFC3986. The XML Signature Element has the following child elements in order in which they appear: ds:SignedInfo. or can envelop the data object that it signs. ds:SignatureMethod. which are used in XML documents as element types and attribute 23 . ds:Reference. comments. The variations in representation of electronic record may be due to the use of different character encodings or insignificant structural differences. "normal". 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. elements. XML schema validation. It has the following child elements: ds: Transforms. ds:SignatureValue. ds: DigestMethod. Transforms can include operations such as canonicalization.―XML Schema‖ is a set of pre-defined or user defined keywords and their attributes arranged in a structured manner. and processing instructions and a physical structure composed of entities. The encrypted digest of the canonical form of the SignedInfo element represents the value of the XML signature. 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. or XInclude. ―XML Transform‖ is an optional ordered list of processing steps applied to the resource's content before it was digested. ―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. digest method (Digestmethod) and digest value (DigestValue) value of referenced data objects. ds:Object and has ID attribute of type (xsd:ID) ―Reference Element‖ carries a references to data objects. It is the main element of XML Signature and it can exist as a standalone document. MimeType. ―Detached Signature‖ references a resource that is separate from the Signature element. ―SignatureValue Element‖ contains the actual value of the digital signature. XPath filtering.. It has many child elements such as: ds: KeyName. provides a structure to carry a list of Reference element elements similar to that provided by the SignedInfo element. keys names. ds: KeyValue.names. 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. This report recommends that KeyInfo MUST be present in the XML Signature and that it MUST have X50Certificate element. ―DigestValue Element‖ contains the value of the digest. It can contain keys. 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. certificates. such as a time stamp or a serial number which are defined by application. ―Object Element‖ is an optional element of XML Signature Element. 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. ds: RetrievalMethod and ds: X509Data. and Extensible Stylesheet Language Transformations (XSLT). ―SignatureProperties Element‖ provides a way to carry additional information about the signature. Namespace declaration allows XML to use various XML vocabularies without having name collision. The data object can embed the XML signature within itself. ―KeyInfo Element‖ is an element that enables key information to be packaged along with the XML Signature. ―DigestMethod Element‖ specifies the digest algorithm to be used for the original data object or transformed if any XML Transforms exists. The data object resides within the same XML document containing the XML signature 24 . the main different is that in the case of Manifest element the processing model is defy by the application. ―XML Transform Element‖ is an optional ordered list of processing steps applied to the data objects before it was digested. Base64 decoding. It has one attribute algorithm. and Encoding. Transforms include canonicalization. ―Manifest Element‖ appear as a child of the Object element. An instance of the Object element is used to contain the resource. The data object is embedded within the XML Signature 25 .―Enveloping Signature‖ references a resource that is contained within the Signature element. No. 1) Subject to the provisions of this section any subscriber may authenticate an electronic record by affixing his XML signature. (4) the private key and the public key are unique to the subscriber and constitute a functioning key pair. "normal". (1) 1.Annexure 2 PROPOSED DRAFT THE SECOND SCHEDULE [See sub-section (1) of section 3A] Electronic Signature or Electronic Authentication Technique and Procedure SL. 26 . Explanation: For the purpose of this schedule. (2) Authentication of an electronic record by affixing XML signature shall be effected by the use of hash ALGORITHM. (3) By the use of the public key of the subscriber the electronic record can be verified. canonicalization. (a)―Canonicalization‖ means a process for converting electronic record that has more than one possible representation into a "standard". xml transformation and asymmetric crypto system to generate an electronic signature record. (b)―XML Transform‖ means an optional ordered list of processing steps applied to the resource's content before it is hashed. Description (2) XML Signature Procedure (3) . or canonical form.