tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5126

 
 
 

CMS Advanced Electronic Signatures (CAdES)

Part 7 of 7, p. 129 to 141
Prev RFC Part

 


prevText      Top      Up      ToC       Page 129 
Annex H (Informative): APIs for the Generation and Verification of
                       Electronic Signatures Tokens

   While the present document describes the data format of an electronic
   signature, the question is whether there exist APIs (Application
   Programming Interfaces) able to manipulate these structures.  At
   least two such APIs have been defined; one set by the IETF and
   another set by the OMG (Object Management Group).

H.1.  Data Framing

   In order to be able to use either of these APIs, it will be necessary
   to frame the previously defined electronic signature data structures
   using a mechanism-independent token format.  Section 3.1 of RFC 2743
   [RFC2743] specifies a mechanism-independent level of encapsulating
   representation for the initial token of a GSS-API context
   establishment sequence, incorporating an identifier of the mechanism
   type to be used on that context and enabling tokens to be interpreted
   unabmiguously.

   In order to be processable by these APIs, all electronic signature
   data formats that are defined in the present document shall be framed
   following that description.

   The encoding format for the token tag is derived from ASN.1 and DER,
   but its concrete representation is defined directly in terms of
   octets rather than at the ASN.1 level, in order to facilitate
   interoperable implementation without use of general ASN.1 processing
   code.  The token tag consists of the following elements, in order:

      1) 0x60 -- Tag for RFC 2743 SEQUENCE; indicates that constructed
         form, definite length encoding follows.

      2) Token-length octets, specifying length of subsequent data
         (i.e., the summed lengths of elements 3 to 5 in this list, and
         of the mechanism-defined token object following the tag).  This
         element comprises a variable number of octets:

         a) If the indicated value is less than 128, it shall be
            represented in a single octet with bit 8 (high order) set to
            "0" and the remaining bits representing the value.

Top      Up      ToC       Page 130 
         b) If the indicated value is 128 or more, it shall be
            represented in two or more octets, with bit 8 of the first
            octet set to "1" and the remaining bits of the first octet
            specifying the number of additional octets.  The subsequent
            octets carry the value, 8 bits per octet, with the most
            significant digit first.  The minimum number of octets shall
            be used to encode the length (i.e., no octets representing
            leading zeros shall be included within the length encoding).

      3) 0x06 -- Tag for OBJECT IDENTIFIER.

      4) Object identifier length -- length (number of octets) of the
         encoded object identifier contained in element 5, encoded per
         rules as described in 2a) and 2b) above.

      5) object identifier octets -- variable number of octets, encoded
         per ASN.1 BER rules:

         - The first octet contains the sum of two values:

            (1) the top-level object identifier component, multiplied by
                40 (decimal); and

            (2) the second-level object identifier component.

                This special case is the only point within an object
                identifier encoding where a single octet represents
                contents of more than one component.

            - Subsequent octets, if required, encode successively lower
              components in the represented object identifier.  A
              component's encoding may span multiple octets, encoding 7
              bits per octet (most significant bits first) and with bit
              8 set to "1" on all but the final octet in the component's
              encoding.  The minimum number of octets shall be used to
              encode each component (i.e., no octets representing
              leading zeros shall be included within a component's
              encoding).

      NOTE: In many implementations, elements 3 to 5 may be stored and
      referenced as a contiguous string constant.

   The token tag is immediately followed by a mechanism-defined token
   object.  Note that no independent size specifier intervenes following
   the object identifier value to indicate the size of the
   mechanism-defined token object.

Top      Up      ToC       Page 131 
   Tokens conforming to the present document shall have the following
   OID in order to be processable by IDUP-APIs:

   id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::=
    { itu-t(0) identified-organization(4) etsi(0)
     electronic-signature-standard (1733) part1 (1) IDUPMechanism (4)
     etsiESv1(1) }

H.2.  IDUP-GSS-APIs Defined by the IETF

   The IETF CAT WG produced, in December 1998, an RFC (RFC 2479
   [RFC2479]) under the name of IDUP-GSS-API (Independent Data Unit
   Protection) able to handle the electronic signature data format
   defined in the present document.

   The IDUP-GSS-API includes support for non-repudiation services.

   It supports evidence generation, where "evidence" is information that
   either by itself, or when used in conjunction with other information,
   is used to establish proof about an event or action, as well as
   evidence verification.

   IDUP supports various types of evidences.  All the types defined in
   IDUP are supported in the present document through the
   commitment-type parameter.

   Section 2.3.3 of IDUP describes the specific calls needed to handle
   evidence ("EV" calls).  The "EV" group of calls provides a simple,
   high-level interface to underlying IDUP mechanisms when application
   developers need to deal with only evidence: not with encryption or
   integrity services.

   All generations and verification are performed according to the
   content of a NR policy that is referenced in the context.

   Get_token_details is used to return the attributes that correspond to
   a given input token to an application.  Since IDUP-GSS-API tokens are
   meant to be opaque to the calling application, this function allows
   the application to determine information about the token without
   having to violate the opaqueness intention of IDUP.  Of primary
   importance is the mechanism type, which the application can then use
   as input to the IDUP_Establish_Env() call in order to establish the
   correct environment in which to have the token processed.

   Generate_token generates a non-repudiation token using the current
   environment.

Top      Up      ToC       Page 132 
   Verify_evidence verifies the evidence token using the current
   environment.  This operation returns a major_status code that can be
   used to determine whether the evidence contained in a token is
   complete (i.e., can be successfully verified (perhaps years) later).
   If a token's evidence is not complete, the token can be passed to
   another API, form_complete_pidu, to complete it.  This happens when a
   status "conditionally valid" is returned.  That status corresponds to
   the status "validation incomplete" of the present document.

   Form_complete_PIDU is used primarily when the evidence token itself
   does not contain all the data required for its verification, and it
   is anticipated that some of the data not stored in the token may
   become unavailable during the interval between generation of the
   evidence token and verification unless it is stored in the token.
   The Form_Complete_PIDU operation gathers the missing information and
   includes it in the token so that verification can be guaranteed to be
   possible at any future time.

H.3.  CORBA Security Interfaces Defined by the OMG

   Non-repudiation interfaces have been defined in "CORBA Security", a
   document produced by the OMG (Object Management Group).  These
   interfaces are described in IDL (Interface Definition Language) and
   are optional.

   The handling of "tokens" supporting non-repudiation is done through
   the following interfaces:

      - set_NR_features specifies the features to apply to future
        evidence generation and verification operations;

      - get_NR_features returns the features that will be applied to
        future evidence generation and verification operations;

      - generate_token generates a non-repudiation token using the
        current non-repudiation features;

      - verify_evidence verifies the evidence token using the current
        non-repudiation features;

      - get_tokens_details returns information about an input
        non-repudiation token.  The information returned depends upon
        the type of token;

      - form_complete_evidence is used when the evidence token itself
        does not contain all the data required for its verification, and
        it is anticipated that some of the data not stored in the token
        may become unavailable during the interval between generation of

Top      Up      ToC       Page 133 
        the evidence token and verification unless it is stored in the
        token.  The form_complete_evidence operation gathers the missing
        information and includes it in the token so that verification
        can be guaranteed to be possible at any future time.

      NOTE: The similarity between the two sets of APIs is noticeable.

Annex I (Informative): Cryptographic Algorithms

   RFC 3370 [10] describes the conventions for using several
   cryptographic algorithms with the Crytographic Message Syntax (CMS).
   Only the hashing and signing algorithms are appropriate for use with
   the present document.

   Since the publication of RFC 3370 [10], MD5 has been broken.  This
   algorithm is no longer considered appropriate and has been deleted
   from the list of algorithms.

I.1.  Digest Algorithms

I.1.1.  SHA-1

   The SHA-1 digest algorithm is defined in FIPS Pub 180-1.  The
   algorithm identifier for SHA-1 is:

sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14)
secsig(3) algorithm(2) 26 }

   The AlgorithmIdentifier parameters field is optional.  If present,
   the parameters field shall contain an ASN.1 NULL.  Implementations
   should accept SHA-1 AlgorithmIdentifiers with absent parameters as
   well as NULL parameters.  Implementations should generate SHA-1
   AlgorithmIdentifiers with NULL parameters.

I.1.2.  General

   The following is a selection of work that has been done in the area
   of digest algorithms or, as they are often called, hash functions:

      - ISO/IEC 10118-1 (1994) [ISO10118-1]: "Information technology -
        Security techniques - Hash-functions - Part 1: General". ISO/IEC
        10118-1 contains definitions and describes basic concepts.

      - ISO/IEC 10118-2 (1994) [ISO10118-2]: "Information technology -
        Security techniques - Hash-functions - Part 2: Hash-functions
        using an n-bit block cipher algorithm".  ISO/IEC 10118-2
        specifies two ways to construct a hash-function from a block
        cipher.

Top      Up      ToC       Page 134 
      - ISO/IEC 10118-3 (1997) [ISO10118-3]: "Information technology -
        Security techniques - Hash-functions - Part 3: Dedicated
        hash-functions".  ISO/IEC 10118-3 specifies the following
        dedicated hash-functions:

         - SHA-1 (FIPS 180-1);
         - RIPEMD-128;
         - RIPEMD-160.

      - ISO/IEC 10118-4 (1998) [ISO10118-4]: "Information technology -
        Security techniques - Hash-functions - Part 4: Hash-functions
        using modular arithmetic".

      - RFC 1320 (PS 1992): "The MD4 Message-Digest Algorithm".  RFC
        1320 specifies the hash-function MD4.  Today, MD4 is considered
        outdated.

      - RFC 1321 (I 1992): "The MD5 Message-Digest Algorithm".  RFC 1321
        (informational) specifies the hash-function MD5.  Today, MD5 is
        not recommended for new implementations.

      - FIPS Publication 180-1 (1995): "Secure Hash Standard".  FIPS
        180-1 specifies the Secure Hash Algorithm (SHA), dedicated hash-
        function developed for use with the DSA.  The original SHA,
        published in 1993, was slightly revised in 1995 and renamed
        SHA-1.

      - ANSI X9.30-2 (1997) [X9.30-2]: "Public Key Cryptography for the
        Financial Services Industry - Part 2: The Secure Hash Algorithm
        (SHA-1)".  X9.30-2 specifies the ANSI-Version of SHA-1.

      - ANSI X9.31-2 (1996) [X9.31-2]: "Public Key Cryptography Using
        Reversible Algorithms for the Financial Services Industry - Part
        2: Hash Algorithms".  X9.31-2 specifies hash algorithms.

I.2.  Digital Signature Algorithms

I.2.1.  DSA

   The DSA signature algorithm is defined in FIPS Pub 186.  DSA is
   always used with the SHA-1 message digest algorithm.  The algorithm
   identifier for DSA is:

id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2) us(840)
x9-57 (10040) x9cm(4) 3 }

   The AlgorithmIdentifier parameters field shall not be present.

Top      Up      ToC       Page 135 
I.2.2.  RSA

   The RSA signature algorithm is defined in RFC 3447 [RFC3447].  RFC
   3370 [10] specifies the use of the RSA signature algorithm with the
   SHA-1 algorithm.  The algorithm identifier for RSA with SHA-1 is:

   Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

      NOTE: RFC 3370 [10] recommends that MD5 not be used for new
      implementations.

I.2.3.  General

      The following is a selection of work that has been done in the
      area of digital signature mechanisms:

      - FIPS Publication 186 (1994): "Digital Signature Standard".
        NIST's Digital Signature Algorithm (DSA) is a variant of
        ElGamal's Discrete Logarithm-based digital signature mechanism.
        The DSA requires a 160-bit hash-function and mandates SHA-1.

      - IEEE P1363 (2000) [P1363]: "Standard Specifications for Public-
        Key Cryptography".  IEEE P1363 contains mechanisms for digital
        signatures, key establishment, and encipherment based on three
        families of public key schemes:

      - "Conventional" Discrete Logarithm (DL)-based techniques, i.e.,
        Diffie-Hellman (DH) key agreement, Menezes-Qu-Vanstone (MQV) key
        agreement, the Digital Signature Algorithm (DSA), and
        Nyberg-Rueppel (NR) digital signatures;

      - Elliptic Curve (EC)-based variants of the DL-mechanisms
        specified above, i.e., EC-DH, EC-MQV, EC-DSA, and EC-NR.  For
        elliptic curves, implementation options include mod p and
        characteristic 2 with polynomial or normal basis representation;

      - Integer Factoring (IF)-based techniques, including RSA
        encryption, RSA digital signatures, and RSA-based key transport.

      - ISO/IEC 9796-2 (1997) [ISO9796-2]: "Information technology -
        Security techniques - Digital signature schemes giving message
        recovery - Part 2: Mechanisms using a hash-function".  ISO/IEC
        9796-2 specifies digital signature mechanisms with partial
        message recovery that are also based on the RSA technique but
        make use of a hash-function.

Top      Up      ToC       Page 136 
      - ISO/IEC 9796-4 (1998) [ISO9796-4]: "Digital signature schemes
        giving message recovery - Part 4: Discrete logarithm based
        mechanisms".  ISO/IEC 9796-4 specifies digital signature
        mechanisms with partial message recovery that are based on
        Discrete Logarithm techniques.  The document includes the
        Nyberg-Rueppel scheme.

      - ISO/IEC 14888-1 [ISO14888-1]: "Digital signatures with appendix
        - Part 1: General".  ISO/IEC 14888-1 contains definitions and
        describes the basic concepts of digital signatures with
        appendix.

      - ISO/IEC 14888-2 [ISO14888-2]: "Digital signatures with appendix
        - Part 2: Identity-based mechanisms".  ISO/IEC 14888-2 specifies
        digital signature schemes with appendix that make use of
        identity-based keying material.  The document includes the
        zero-knowledge techniques of Fiat-Shamir and Guillou-Quisquater.

      - ISO/IEC 14888-3 [ISO14888-3]: "Digital signatures with appendix
        - Part 3: Certificate-based mechanisms".  ISO/IEC 14888-3
        specifies digital signature schemes with appendix that make use
        of certificate-based keying material.  The document includes
        five schemes:

         - DSA;
         - EC-DSA, an elliptic curve-based analog of NIST's Digital
           Signature Algorithm;
         - Pointcheval-Vaudeney signatures;
         - RSA signatures;
         - ESIGN.

      - ISO/IEC 15946-2 (2002) [ISO15946-2]: "Cryptographic techniques
        based on elliptic curves - Part 2: Digital signatures",
        specifies digital signature schemes with appendix using elliptic
        curves.

      - The document includes two schemes:

        - EC-DSA, an elliptic curve-based analog of NIST's Digital
          Signature Algorithm;

        - EC-AMV, an elliptic curve-based analog of the Agnew-Muller-
          Vanstone signature algorithm.

Top      Up      ToC       Page 137 
      - ANSI X9.31-1 (1997) [X9.31-1]: "Public Key Cryptography Using
        Reversible Algorithms for the Financial Services Industry - Part
        1: The RSA Signature Algorithm".  ANSI X9.31-1 specifies a
        digital signature mechanism with appendix using the RSA public
        key technique.

      - ANSI X9.30-1 (1997) [X9.30-1]: "Public Key Cryptography Using
        Irreversible Algorithms for the Financial Services Industry -
        Part 1: The Digital Signature Algorithm (DSA)".  ANSI X9.30-1
        specifies the DSA, NIST's Digital Signature Algorithm.

      - ANSI X9.62 (1998) [X9.62]: "Public Key Cryptography for the
        Financial Services Industry - The Elliptic Curve Digital
        Signature Algorithm (ECDSA)".  ANSI X9.62 specifies the Elliptic
        Curve Digital Signature Algorithm, an analog of NIST's Digital
        Signature Algorithm (DSA) using elliptic curves.  The appendices
        provide tutorial information on the underlying mathematics for
        elliptic curve cryptography and give many examples.

Annex J (Informative): Guidance on Naming

J.1.  Allocation of Names

   The subject name shall be allocated through a registration scheme
   administered through a Registration Authority (RA) to ensure
   uniqueness.  This RA may be an independent body or a function carried
   out by the Certification Authority.

   In addition to ensuring uniqueness, the RA shall verify that the name
   allocated properly identifies the applicant and that authentication
   checks are carried out to protect against masquerade.

   The name allocated by an RA is based on registration information
   provided by, or relating to, the applicant (e.g., his personal name,
   date of birth, residence address) and information allocated by the
   RA. Three variations commonly exist:

      - the name is based entirely on registration information, which
        uniquely identifies the applicant (e.g., "Pierre Durand (born
        on) July 6, 1956");

      - the name is based on registration information, with the addition
        of qualifiers added by the registration authority to ensure
        uniqueness (e.g., "Pierre Durand 12");

      - the registration information is kept private by the registration
        authority and the registration authority allocates a
        "pseudonym".

Top      Up      ToC       Page 138 
J.2.  Providing Access to Registration Information

   Under certain circumstances, it may be necessary for information used
   during registration, but not published in the certificate, to be made
   available to third parties (e.g., to an arbitrator to resolve a
   dispute or for law enforcement).  This registration information is
   likely to include personal and sensitive information.

   Thus, the RA needs to establish a policy for:

         - whether the registration information should be disclosed;
         - to whom such information should be disclosed;
         - under what circumstances such information should be
           disclosed.

   This policy may be different whether the RA is being used only within
   a company or for public use.  The policy will have to take into
   account national legislation and in particular any data protection
   and privacy legislation.

   Currently, the provision of access to registration is a local matter
   for the RA.  However, if open access is required, standard protocols,
   such as HTTP -- RFC 2068 (Internet Web Access Protocol), may be
   employed with the addition of security mechanisms necessary to meet
   the data protection requirements (e.g., Transport Layer Security --
   RFC 4346 [RFC4346]) with client authentication.

J.3.  Naming Schemes

J.3.1.  Naming Schemes for Individual Citizens

   In some cases, the subject name that is contained in a public key
   certificate may not be meaningful enough.  This may happen because of
   the existence of homonyms or because of the use of pseudonyms.  A
   distinction could be made if more attributes were present.  However,
   adding more attributes to a public key certificate placed in a public
   repository would be going against the privacy protection
   requirements.

   In any case, the Registration Authority will get information at the
   time of registration, but not all that information will be placed in
   the certificate.  In order to achieve a balance between these two
   opposite requirements, the hash values of some additional attributes
   can be placed in a public key certificate.  When the certificate
   owner provides these additional attributes, then they can be
   verified.  Using biometrics attributes may unambiguously identify a
   person.  Examples of biometrics attributes that can be used include:
   a picture or a manual signature from the certificate owner.

Top      Up      ToC       Page 139 
      NOTE: Using hash values protects privacy only if the possible
      inputs are large enough.  For example, using the hash of a
      person's social security number is generally not sufficient since
      it can easily be reversed.

   A picture can be used if the verifier once met the person and later
   on wants to verify that the certificate that he or she got relates to
   the person whom was met.  In such a case, at the first exchange, the
   picture is sent, and the hash contained in the certificate may be
   used by the verifier to verify that it is the right person.  At the
   next exchange, the picture does not need to be sent again.

   A manual signature may be used if a signed document has been received
   beforehand.  In such a case, at the first exchange, the drawing of
   the manual signature is sent, and the hash contained in the
   certificate may be used by the verifier to verify that it is the
   right manual signature.  At the next exchange, the manual signature
   does not need to be sent again.

J.3.2.  Naming Schemes for Employees of an Organization

   The name of an employee within an organization is likely to be some
   combination of the name of the organization and the identifier of the
   employee within that organization.

   An organization name is usually a registered name, i.e., business or
   trading name used in day-to-day business.  This name is registered by
   a Naming Authority, which guarantees that the organization's
   registered name is unambiguous and cannot be confused with another
   organization.

   In order to get more information about a given registered
   organization name, it is necessary to go back to a publicly available
   directory maintained by the Naming Authority.

   The identifier may be a name or a pseudonym (e.g., a nickname or an
   employee number).  When it is a name, it is supposed to be
   descriptive enough to unambiguously identify the person.  When it is
   a pseudonym, the certificate does not disclose the identity of the
   person.  However, it ensures that the person has been correctly
   authenticated at the time of registration and therefore may be
   eligible to some advantages implicitly or explicitly obtained through
   the possession of the certificate.  In either case, however, this can
   be insufficient because of the existence of homonyms.

   Placing more attributes in the certificate may be one solution, for
   example, by giving the organization unit of the person or the name of
   a city where the office is located.  However, the more information is

Top      Up      ToC       Page 140 
   placed in the certificate, the more problems arise if there is a
   change in the organization structure or the place of work.  So this
   may not be the best solution.  An alternative is to provide more
   attributes (like the organization unit and the place of work) through
   access to a directory maintained by the company.  It is likely that,
   at the time of registration, the Registration Authority got more
   information than what was placed in the certificate, if such
   additional information is placed in a repository accessible only to
   the organization.

Acknowledgments

   Special thanks to Russ Housley for reviewing the document.

Authors' Addresses

   Denis Pinkas
   Bull SAS
   Rue Jean-Jaures
   78340 Les Clayes sous Bois CEDEX
   FRANCE
   EMail: Denis.Pinkas@bull.net

   Nick Pope
   Thales eSecurity
   Meadow View House
   Long Crendon
   Aylesbury
   Buck
   HP18 9EQ
   United Kingdom
   EMail: nick.pope@thales-esecurity.com

   John Ross
   Security & Standards Consultancy Ltd
   The Waterhouse Business Centre
   2 Cromer Way
   Chelmsford
   Essex
   CM1 2QE
   United Kingdom
   EMail: ross@secstan.com

Top      Up      ToC       Page 141 
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.