Table v2.4 serial key or number
Table v2.4 serial key or number
Numeric types consist of two-, four-, and eight-byte integers, four- and eight-byte floating-point numbers, and selectable-precision decimals. Table 8.2 lists the available types.
Table 8.2. Numeric Types
| Name | Storage Size | Description | Range |
|---|---|---|---|
| 2 bytes | small-range integer | -32768 to +32767 | |
| 4 bytes | typical choice for integer | -2147483648 to +2147483647 | |
| 8 bytes | large-range integer | -9223372036854775808 to +9223372036854775807 | |
| variable | user-specified precision, exact | up to 131072 digits before the decimal point; up to 16383 digits after the decimal point | |
| variable | user-specified precision, exact | up to 131072 digits before the decimal point; up to 16383 digits after the decimal point | |
| 4 bytes | variable-precision, inexact | 6 decimal digits precision | |
| 8 bytes | variable-precision, inexact | 15 decimal digits precision | |
| 2 bytes | small autoincrementing integer | 1 to 32767 | |
| 4 bytes | autoincrementing integer | 1 to 2147483647 | |
| 8 bytes | large autoincrementing integer | 1 to 9223372036854775807 |
The syntax of constants for the numeric types is described in Section 4.1.2. The numeric types have a full set of corresponding arithmetic operators and functions. Refer to Chapter 9 for more information. The following sections describe the types in detail.
8.1.1. Integer Types
The types , , and store whole numbers, that is, numbers without fractional components, of various ranges. Attempts to store values outside of the allowed range will result in an error.
The type is the common choice, as it offers the best balance between range, storage size, and performance. The type is generally only used if disk space is at a premium. The type is designed to be used when the range of the type is insufficient.
only specifies the integer types (or ), , and . The type names , , and are extensions, which are also used by some other database systems.
8.1.2. Arbitrary Precision Numbers
The type can store numbers with a very large number of digits. It is especially recommended for storing monetary amounts and other quantities where exactness is required. Calculations with values yield exact results where possible, e.g. addition, subtraction, multiplication. However, calculations on values are very slow compared to the integer types, or to the floating-point types described in the next section.
We use the following terms below: The precision of a is the total count of significant digits in the whole number, that is, the number of digits to both sides of the decimal point. The scale of a is the count of decimal digits in the fractional part, to the right of the decimal point. So the number 23.5141 has a precision of 6 and a scale of 4. Integers can be considered to have a scale of zero.
Both the maximum precision and the maximum scale of a column can be configured. To declare a column of type use the syntax:
NUMERIC(, )The precision must be positive, the scale zero or positive. Alternatively:
NUMERIC()selects a scale of 0. Specifying:
NUMERICwithout any precision or scale creates a column in which numeric values of any precision and scale can be stored, up to the implementation limit on precision. A column of this kind will not coerce input values to any particular scale, whereas columns with a declared scale will coerce input values to that scale. (The standard requires a default scale of 0, i.e., coercion to integer precision. We find this a bit useless. If you're concerned about portability, always specify the precision and scale explicitly.)
Note
The maximum allowed precision when explicitly specified in the type declaration is 1000; without a specified precision is subject to the limits described in Table 8.2.
If the scale of a value to be stored is greater than the declared scale of the column, the system will round the value to the specified number of fractional digits. Then, if the number of digits to the left of the decimal point exceeds the declared precision minus the declared scale, an error is raised.
Numeric values are physically stored without any extra leading or trailing zeroes. Thus, the declared precision and scale of a column are maximums, not fixed allocations. (In this sense the type is more akin to than to .) The actual storage requirement is two bytes for each group of four decimal digits, plus three to eight bytes overhead.
In addition to ordinary numeric values, the type allows the special value , meaning “not-a-number”. Any operation on yields another . When writing this value as a constant in an SQL command, you must put quotes around it, for example . On input, the string is recognized in a case-insensitive manner.
Note
In most implementations of the “not-a-number” concept, is not considered equal to any other numeric value (including ). In order to allow values to be sorted and used in tree-based indexes, PostgreSQL treats values as equal, and greater than all non- values.
The types and are equivalent. Both types are part of the standard.
When rounding values, the type rounds ties away from zero, while (on most machines) the and types round ties to the nearest even number. For example:
SELECT x, round(x::numeric) AS num_round, round(x::double precision) AS dbl_round FROM generate_series(-3.5, 3.5, 1) as x; x | num_round | dbl_round ------+-----------+----------- -3.5 | -4 | -4 -2.5 | -3 | -2 -1.5 | -2 | -2 -0.5 | -1 | -0 0.5 | 1 | 0 1.5 | 2 | 2 2.5 | 3 | 2 3.5 | 4 | 4 (8 rows)8.1.3. Floating-Point Types
The data types and are inexact, variable-precision numeric types. On all currently supported platforms, these types are implementations of Standard 754 for Binary Floating-Point Arithmetic (single and double precision, respectively), to the extent that the underlying processor, operating system, and compiler support it.
Inexact means that some values cannot be converted exactly to the internal format and are stored as approximations, so that storing and retrieving a value might show slight discrepancies. Managing these errors and how they propagate through calculations is the subject of an entire branch of mathematics and computer science and will not be discussed here, except for the following points:
If you require exact storage and calculations (such as for monetary amounts), use the type instead.
If you want to do complicated calculations with these types for anything important, especially if you rely on certain behavior in boundary cases (infinity, underflow), you should evaluate the implementation carefully.
Comparing two floating-point values for equality might not always work as expected.
On all currently supported platforms, the type has a range of around 1E-37 to 1E+37 with a precision of at least 6 decimal digits. The type has a range of around 1E-307 to 1E+308 with a precision of at least 15 digits. Values that are too large or too small will cause an error. Rounding might take place if the precision of an input number is too high. Numbers too close to zero that are not representable as distinct from zero will cause an underflow error.
By default, floating point values are output in text form in their shortest precise decimal representation; the decimal value produced is closer to the true stored binary value than to any other value representable in the same binary precision. (However, the output value is currently never exactly midway between two representable values, in order to avoid a widespread bug where input routines do not properly respect the round-to-nearest-even rule.) This value will use at most 17 significant decimal digits for values, and at most 9 digits for values.
Note
This shortest-precise output format is much faster to generate than the historical rounded format.
For compatibility with output generated by older versions of PostgreSQL, and to allow the output precision to be reduced, the extra_float_digits parameter can be used to select rounded decimal output instead. Setting a value of 0 restores the previous default of rounding the value to 6 (for ) or 15 (for ) significant decimal digits. Setting a negative value reduces the number of digits further; for example -2 would round output to 4 or 13 digits respectively.
Any value of extra_float_digits greater than 0 selects the shortest-precise format.
Note
Applications that wanted precise values have historically had to set extra_float_digits to 3 to obtain them. For maximum compatibility between versions, they should continue to do so.
In addition to ordinary numeric values, the floating-point types have several special values:
These represent the IEEE 754 special values “infinity”, “negative infinity”, and “not-a-number”, respectively. When writing these values as constants in an SQL command, you must put quotes around them, for example . On input, these strings are recognized in a case-insensitive manner.
Note
IEEE754 specifies that should not compare equal to any other floating-point value (including ). In order to allow floating-point values to be sorted and used in tree-based indexes, PostgreSQL treats values as equal, and greater than all non- values.
PostgreSQL also supports the SQL-standard notations and for specifying inexact numeric types. Here, specifies the minimum acceptable precision in binary digits. PostgreSQL accepts to as selecting the type, while to select . Values of outside the allowed range draw an error. with no precision specified is taken to mean .
Note
This section describes a PostgreSQL-specific way to create an autoincrementing column. Another way is to use the SQL-standard identity column feature, described at CREATE TABLE.
The data types , and are not true types, but merely a notational convenience for creating unique identifier columns (similar to the property supported by some other databases). In the current implementation, specifying:
CREATE TABLE ( SERIAL );is equivalent to specifying:
CREATE SEQUENCE __seq AS integer; CREATE TABLE ( integer NOT NULL DEFAULT nextval('__seq') ); ALTER SEQUENCE __seq OWNED BY .;Thus, we have created an integer column and arranged for its default values to be assigned from a sequence generator. A constraint is applied to ensure that a null value cannot be inserted. (In most cases you would also want to attach a or constraint to prevent duplicate values from being inserted by accident, but this is not automatic.) Lastly, the sequence is marked as “owned by” the column, so that it will be dropped if the column or table is dropped.
Note
Because , and are implemented using sequences, there may be "holes" or gaps in the sequence of values which appears in the column, even if no rows are ever deleted. A value allocated from the sequence is still "used up" even if a row containing that value is never successfully inserted into the table column. This may happen, for example, if the inserting transaction rolls back. See in Section 9.16 for details.
To insert the next value of the sequence into the column, specify that the column should be assigned its default value. This can be done either by excluding the column from the list of columns in the statement, or through the use of the key word.
The type names and are equivalent: both create columns. The type names and work the same way, except that they create a column. should be used if you anticipate the use of more than 231 identifiers over the lifetime of the table. The type names and also work the same way, except that they create a column.
The sequence created for a column is automatically dropped when the owning column is dropped. You can drop the sequence without dropping the column, but this will force removal of the column default expression.
2 Platform- and compiler-dependent directives for C or C++
This document describes the basic PKCS#11 token interface and token behavior.
The PKCS#11 standard specifies an application programming interface (API), called “Cryptoki,” for devices that hold cryptographic information and perform cryptographic functions. Cryptoki follows a simple object based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a “cryptographic token”.
This document specifies the data types and functions available to an application requiring cryptographic services using the ANSI C programming language. The supplier of a Cryptoki library implementation typically provides these data types and functions via ANSI C header files. Generic ANSI C header files for Cryptoki are available from the PKCS#11 web page. This document and up-to-date errata for Cryptoki will also be available from the same place.
Additional documents may provide a generic, language-independent Cryptoki interface and/or bindings between Cryptoki and other programming languages.
Cryptoki isolates an application from the details of the cryptographic device. The application does not have to change to interface to a different type of device or to run in a different environment; thus, the application is portable. How Cryptoki provides this isolation is beyond the scope of this document, although some conventions for the support of multiple types of device will be addressed here and possibly in a separate document.
Details of cryptographic mechanisms (algorithms) may be found in the associated PKCS#11 Mechanisms documents.
1.1 Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
1.2 Definitions
For the purposes of this standard, the following definitions apply:
API Application programming interface.
Application Any computer program that calls the Cryptoki interface.
ASN.1 Abstract Syntax Notation One, as defined in X.680.
Attribute A characteristic of an object.
BER Basic Encoding Rules, as defined in X.690.
CBC Cipher-Block Chaining mode, as defined in FIPS PUB 81.
Certificate A signed message binding a subject name and a public key, or a subject name and a set of attributes.
CMS Cryptographic Message Syntax (see RFC 5652)
Cryptographic Device A device storing cryptographic information and possibly performing cryptographic functions. May be implemented as a smart card, smart disk, PCMCIA card, or with some other technology, including software-only.
Cryptoki The Cryptographic Token Interface defined in this standard.
Cryptoki library A library that implements the functions specified in this standard.
DER Distinguished Encoding Rules, as defined in X.690.
DES Data Encryption Standard, as defined in FIPS PUB 46-3.
DSA Digital Signature Algorithm, as defined in FIPS PUB 186-4.
EC Elliptic Curve
ECB Electronic Codebook mode, as defined in FIPS PUB 81.
IV Initialization Vector.
MAC Message Authentication Code.
Mechanism A process for implementing a cryptographic operation.
Object An item that is stored on a token. May be data, a certificate, or a key.
PIN Personal Identification Number.
PKCS Public-Key Cryptography Standards.
PRF Pseudo random function.
PTD Personal Trusted Device, as defined in MeT-PTD
RSA The RSA public-key cryptosystem.
Reader The means by which information is exchanged with a device.
Session A logical connection between an application and a token.
Slot A logical reader that potentially contains a token.
SSL The Secure Sockets Layer 3.0 protocol.
Subject Name The X.500 distinguished name of the entity to which a key is assigned.
SO A Security Officer user.
TLS Transport Layer Security.
Token The logical view of a cryptographic device defined by Cryptoki.
User The person using an application that interfaces to Cryptoki.
UTF-8 Universal Character Set (UCS) transformation format (UTF) that represents ISO 10646 and UNICODE strings with a variable number of octets.
WIM Wireless Identification Module.
WTLS Wireless Transport Layer Security.
1.3 Symbols and abbreviations
The following symbols are used in this standard:
Table 1, Symbols
Symbol | Definition |
N/A | Not applicable |
R/O | Read-only |
R/W | Read/write |
The following prefixes are used in this standard:
Table 2, Prefixes
Prefix | Description |
C_ | Function |
CK_ | Data type or general constant |
CKA_ | Attribute |
CKC_ | Certificate type |
CKD_ | Key derivation function |
CKF_ | Bit flag |
CKG_ | Mask generation function |
CKH_ | Hardware feature type |
CKK_ | Key type |
CKM_ | Mechanism type |
CKN_ | Notification |
CKO_ | Object class |
CKP_ | Pseudo-random function |
CKS_ | Session state |
CKR_ | Return value |
CKU_ | User type |
CKZ_ | Salt/Encoding parameter source |
h | a handle |
ul | a CK_ULONG |
p | a pointer |
pb | a pointer to a CK_BYTE |
ph | a pointer to a handle |
pul | a pointer to a CK_ULONG |
Cryptoki is based on ANSI C types, and defines the following data types:
/* an unsigned 8-bit value */
typedef unsigned char CK_BYTE;
/* an unsigned 8-bit character */
typedef CK_BYTE CK_CHAR;
/* an 8-bit UTF-8 character */
typedef CK_BYTE CK_UTF8CHAR;
/* a BYTE-sized Boolean flag */
typedef CK_BYTE CK_BBOOL;
/* an unsigned value, at least 32 bits long */
typedef unsigned long int CK_ULONG;
/* a signed value, the same size as a CK_ULONG */
typedef long int CK_LONG;
/* at least 32 bits; each bit is a Boolean flag */
typedef CK_ULONG CK_FLAGS;
Cryptoki also uses pointers to some of these data types, as well as to the type void, which are implementation-dependent. These pointer types are:
CK_BYTE_PTR /* Pointer to a CK_BYTE */
CK_CHAR_PTR /* Pointer to a CK_CHAR */
CK_UTF8CHAR_PTR /* Pointer to a CK_UTF8CHAR */
CK_ULONG_PTR /* Pointer to a CK_ULONG */
CK_VOID_PTR /* Pointer to a void */
Cryptoki also defines a pointer to a CK_VOID_PTR, which is implementation-dependent:
CK_VOID_PTR_PTR /* Pointer to a CK_VOID_PTR */
In addition, Cryptoki defines a C-style NULL pointer, which is distinct from any valid pointer:
NULL_PTR /* A NULL pointer */
It follows that many of the data and pointer types will vary somewhat from one environment to another (e.g., a CK_ULONG will sometimes be 32 bits, and sometimes perhaps 64 bits). However, these details should not affect an application, assuming it is compiled with Cryptoki header files consistent with the Cryptoki library to which the application is linked.
All numbers and values expressed in this document are decimal, unless they are preceded by “0x”, in which case they are hexadecimal values.
The CK_CHAR data type holds characters from the following table, taken from ANSI C:
Table 3, Character Set
Category | Characters |
Letters | A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z |
Numbers | 0 1 2 3 4 5 6 7 8 9 |
Graphic characters | ! “ # % & ‘ ( ) * + , - . / : ; < = > ? [ \ ] ^ _ { | } ~ |
Blank character | ‘ ‘ |
The CK_UTF8CHAR data type holds UTF-8 encoded Unicode characters as specified in RFC2279. UTF-8 allows internationalization while maintaining backward compatibility with the Local String definition of PKCS #11 version 2.01.
In Cryptoki, the CK_BBOOL data type is a Boolean type that can be true or false. A zero value means false, and a nonzero value means true. Similarly, an individual bit flag, CKF_..., can also be set (true) or unset (false). For convenience, Cryptoki defines the following macros for use with values of type CK_BBOOL:
#define CK_FALSE 0
#define CK_TRUE 1
For backwards compatibility, header files for this version of Cryptoki also define TRUE and FALSE as (CK_DISABLE_TRUE_FALSE may be set by the application vendor):
#ifndef CK_DISABLE_TRUE_FALSE
#ifndef FALSE
#define FALSE CK_FALSE
#endif
#ifndef TRUE
#define TRUE CK_TRUE
#endif
#endif
1.4 Normative References
[FIPS PUB 46-3] NIST. FIPS 46-3: Data Encryption Standard. October 1999.
URL: http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
[FIPS PUB 81] NIST. FIPS 81: DES Modes of Operation. December 1980.
URL: http://csrc.nist.gov/publications/fips/fips81/fips81.htm
[FIPS PUB 186-4] NIST. FIPS 186-4: Digital Signature Standard. July, 2013.
URL: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
[PKCS11-Curr]PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40. Edited by Susan Gleeson and Chris Zimman. 14 April 2015. OASIS Standard. http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/os/pkcs11-curr-v2.40-os.html. Latest version: http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html.
[PKCS11-Hist]PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40. Edited by Susan Gleeson and Chris Zimman. 14 April 2015. OASIS Standard. http://docs.oasis-open.org/pkcs11/pkcs11-hist/v2.40/os/pkcs11-hist-v2.40-os.html. Latest version: http://docs.oasis-open.org/pkcs11/pkcs11-hist/v2.40/pkcs11-hist-v2.40.html.
[PKCS11-Prof]PKCS #11 Cryptographic Token Interface Profiles Version 2.40. Edited by Tim Hudson. 14 April 2015. OASIS Standard. http://docs.oasis-open.org/pkcs11/pkcs11-profiles/v2.40/os/pkcs11-profiles-v2.40-os.html. Latest version: http://docs.oasis-open.org/pkcs11/pkcs11-profiles/v2.40/pkcs11-profiles-v2.40.html.
[PKCS #1] RSA Laboratories. RSA Cryptography Standard. v2.1, June 14, 2002.
URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf
[PKCS #3] RSA Laboratories. Diffie-Hellman Key-Agreement Standard. v1.4, November 1993.
URL: ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-3.doc
[PKCS #5] RSA Laboratories. Password-Based Encryption Standard. v2.0, March 25, 1999
URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf
[PKCS #7] RSA Laboratories. Cryptographic Message Syntax Standard.v1.5, November 1993
URL : ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-7.doc
[PKCS #8] RSA Laboratories. Private-Key Information Syntax Standard. v1.2, November 1993.
URL: ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-8.doc
[PKCS11-UG]PKCS #11 Cryptographic Token Interface Usage Guide Version 2.40. Edited by John Leiseboer and Robert Griffin. 16 November 2014. OASIS Committee Note 02. http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html. Latest version: http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/pkcs11-ug-v2.40.html.
[PKCS #12] RSA Laboratories. Personal Information Exchange Syntax Standard. v1.0, June 1999.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
URL: http://www.ietf.org/rfc/rfc2119.txt.
[RFC 2279] F. Yergeau. RFC 2279: UTF-8, a transformation format of ISO 10646 Alis Technologies, January 1998. URL: http://www.ietf.org/rfc/rfc2279.txt
[RFC 2534] Masinter, L., Wing, D., Mutz, A., and K. Holtman. RFC 2534: Media Features for Display, Print, and Fax. March 1999. URL: http://www.ietf.org/rfc/rfc2534.txt
[TLS] IETF. RFC 2246: The TLS Protocol Version 1.0 . January 1999.
URL: http://www.ietf.org/rfc/rfc2246.txt
[RFC 5652] R. Housley. RFC 5652: Cryptographic Message Syntax. Septmber 2009. URL: http://www.ietf.org/rfc/rfc5652.txt
[X.500] ITU-T. Information Technology — Open Systems Interconnection — The Directory: Overview of Concepts, Models and Services. February 2001. Identical to ISO/IEC 9594-1
[X.509] ITU-T. Information Technology — Open Systems Interconnection — The Directory: Public-key and Attribute Certificate Frameworks. March 2000.
Identical to ISO/IEC 9594-8
[X.680] ITU-T. Information Technology — Abstract Syntax Notation One (ASN.1): Specification of Basic Notation. July 2002.
Identical to ISO/IEC 8824-1
[X.690] ITU-T. Information Technology — ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER). July 2002.
Identical to ISO/IEC 8825-1
1.5 Non-Normative References
[ANSI C] ANSI/ISO. American National Standard for Programming Languages – C. 1990.
[CC/PP] W3C. Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies. World Wide Web Consortium, January 2004.
URL: http://www.w3.org/TR/CCPP-struct-vocab/
[CDPD] Ameritech Mobile Communications et al. Cellular Digital Packet Data System Specifications: Part 406: Airlink Security. 1993.
[GCS-API] X/Open Company Ltd. Generic Cryptographic Service API (GCS-API), Base - Draft 2. February 14, 1995.
[ISO/IEC 7816-1] ISO. Information Technology — Identification Cards — Integrated Circuit(s) with Contacts — Part 1: Physical Characteristics. 1998.
[ISO/IEC 7816-4] ISO. Information Technology — Identification Cards — Integrated Circuit(s) with Contacts — Part 4: Interindustry Commands for Interchange. 1995.
[ISO/IEC 8824-1] ISO. Information Technology-- Abstract Syntax Notation One (ASN.1): Specification of Basic Notation. 2002.
[ISO/IEC 8825-1] ISO. Information Technology—ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER). 2002.
[ISO/IEC 9594-1] ISO. Information Technology — Open Systems Interconnection — The Directory: Overview of Concepts, Models and Services. 2001.
[ISO/IEC 9594-8] ISO. Information Technology — Open Systems Interconnection — The Directory: Public-key and Attribute Certificate Frameworks. 2001
[ISO/IEC 9796-2] ISO. Information Technology — Security Techniques — Digital Signature Scheme Giving Message Recovery — Part 2: Integer factorization based mechanisms. 2002.
[Java MIDP] Java Community Process. Mobile Information Device Profile for Java 2 Micro Edition. November 2002.
URL: http://jcp.org/jsr/detail/118.jsp
[MeT-PTD] MeT. MeT PTD Definition – Personal Trusted Device Definition, Version 1.0, February 2003.
URL: http://www.mobiletransaction.org
[PCMCIA] Personal Computer Memory Card International Association. PC Card Standard, Release 2.1,. July 1993.
[SEC 1] Standards for Efficient Cryptography Group (SECG). Standards for Efficient Cryptography (SEC) 1: Elliptic Curve Cryptography. Version 1.0, September 20, 2000.
[SEC 2] Standards for Efficient Cryptography Group (SECG). Standards for Efficient Cryptography (SEC) 2: Recommended Elliptic Curve Domain Parameters. Version 1.0, September 20, 2000.
[WIM] WAP. Wireless Identity Module. — WAP-260-WIM-20010712-a. July 2001.
URL: http://technical.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-260-wim-20010712-a.pdf
[WPKI] Wireless Application Protocol: Public Key Infrastructure Definition. — WAP-217-WPKI-20010424-a. April 2001.
URL: http://technical.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-217-wpki-20010424-a.pdf
[WTLS] WAP. Wireless Transport Layer Security Version — WAP-261-WTLS-20010406-a. April 2001.
URL: http://technical.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-261-wtls-20010406-a.pdf
There is a large array of Cryptoki-related data types that are defined in the Cryptoki header files. Certain packing and pointer-related aspects of these types are platform and compiler-dependent; these aspects are therefore resolved on a platform-by-platform (or compiler-by-compiler) basis outside of the Cryptoki header files by means of preprocessor directives.
This means that when writing C or C++ code, certain preprocessor directives MUST be issued before including a Cryptoki header file. These directives are described in the remainder of Section 6.
2.1 Structure packing
Cryptoki structures are packed to occupy as little space as is possible. Cryptoki structures SHALL be packed with 1-byte alignment.
2.2 Pointer-related macros
Because different platforms and compilers have different ways of dealing with different types of pointers, the following 6 macros SHALL be set outside the scope of Cryptoki:
¨ CK_PTR
CK_PTR is the “indirection string” a given platform and compiler uses to make a pointer to an object. It is used in the following fashion:
typedef CK_BYTE CK_PTR CK_BYTE_PTR;
¨ CK_DEFINE_FUNCTION
CK_DEFINE_FUNCTION(returnType, name), when followed by a parentheses-enclosed list of arguments and a function definition, defines a Cryptoki API function in a Cryptoki library. returnType is the return type of the function, and name is its name. It SHALL be used in the following fashion:
CK_DEFINE_FUNCTION(CK_RV, C_Initialize)(
CK_VOID_PTR pReserved
)
{
...
}
¨ CK_DECLARE_FUNCTION
CK_DECLARE_FUNCTION(returnType, name), when followed by a parentheses-enclosed list of arguments and a semicolon, declares a Cryptoki API function in a Cryptoki library. returnType is the return type of the function, and name is its name. It SHALL be used in the following fashion:
CK_DECLARE_FUNCTION(CK_RV, C_Initialize)(
CK_VOID_PTR pReserved
);
¨ CK_DECLARE_FUNCTION_POINTER
CK_DECLARE_FUNCTION_POINTER(returnType, name), when followed by a parentheses-enclosed list of arguments and a semicolon, declares a variable or type which is a pointer to a Cryptoki API function in a Cryptoki library. returnType is the return type of the function, and name is its name. It SHALL be used in either of the following fashions to define a function pointer variable, myC_Initialize, which can point to a C_Initialize function in a Cryptoki library (note that neither of the following code snippets actually assigns a value to myC_Initialize):
CK_DECLARE_FUNCTION_POINTER(CK_RV, myC_Initialize)(
CK_VOID_PTR pReserved
);
or:
typedef CK_DECLARE_FUNCTION_POINTER(CK_RV, myC_InitializeType)(
CK_VOID_PTR pReserved
);
myC_InitializeType myC_Initialize;
¨ CK_CALLBACK_FUNCTION
CK_CALLBACK_FUNCTION(returnType, name), when followed by a parentheses-enclosed list of arguments and a semicolon, declares a variable or type which is a pointer to an application callback function that can be used by a Cryptoki API function in a Cryptoki library. returnType is the return type of the function, and name is its name. It SHALL be used in either of the following fashions to define a function pointer variable, myCallback, which can point to an application callback which takes arguments args and returns a CK_RV (note that neither of the following code snippets actually assigns a value to myCallback):
CK_CALLBACK_FUNCTION(CK_RV, myCallback)(args);
or:
typedef CK_CALLBACK_FUNCTION(CK_RV, myCallbackType)(args);
myCallbackType myCallback;
¨ NULL_PTR
NULL_PTRis the value of a NULL pointer. In any ANSI C environment—and in many others as well—NULL_PTR SHALL be defined simply as 0.
The general Cryptoki data types are described in the following subsections. The data types for holding parameters for various mechanisms, and the pointers to those parameters, are not described here; these types are described with the information on the mechanisms themselves, in Section 12.
A C or C++ source file in a Cryptoki application or library can define all these types (the types described here and the types that are specifically used for particular mechanism parameters) by including the top-level Cryptoki include file, pkcs11.h. pkcs11.h, in turn, includes the other Cryptoki include files, pkcs11t.h and pkcs11f.h. A source file can also include just pkcs11t.h (instead of pkcs11.h); this defines most (but not all) of the types specified here.
When including either of these header files, a source file MUST specify the preprocessor directives indicated in Section 2.
3.1 General information
Cryptoki represents general information with the following types:
¨ CK_VERSION; CK_VERSION_PTR
CK_VERSION is a structure that describes the version of a Cryptoki interface, a Cryptoki library, or an SSL implementation, or the hardware or firmware version of a slot or token. It is defined as follows:
typedef struct CK_VERSION {
CK_BYTE major;
CK_BYTE minor;
} CK_VERSION;
The fields of the structure have the following meanings:
major major version number (the integer portion of the version)
minor minor version number (the hundredths portion of the version)
Example: For version 1.0, major = 1 and minor = 0. For version 2.10, major = 2 and minor = 10. Table 4 below lists the major and minor version values for the officially published Cryptoki specifications.
Table 4, Major and minor version values for published Cryptoki specifications
Serial numbers, redemption codes, and product codes | Student and Teacher editions
An email from the reseller
Find your 19-digit numeric product code in an email from the reseller from which you purchased your product.
Follow the instructions in the email.
Depending on your region, go to one of the following sites to submit your verification request or find out how to do so:
North America: www.adobe.com/go/edu-validate
Outside North America, one of the following:
Europe, Middle East, Africa | Germany | France | Spain | Italy | Netherlands | Czech Republic | Poland | Asia/Pacific | Korea | Japan
Verification can take 2–30 days.
Once your verification request has been approved, you receive an email with a 24-digit numeric serial number.
Make note of your serial number and enter your serial number when prompted during installation of your product.
Make sure that you retain the serial number in case you ever need to update your product or receive product support. Consider registering your Adobe product, which securely stores your serial number in your Adobe account.
Not applicable.
What’s New in the Table v2.4 serial key or number?
Screen Shot
System Requirements for Table v2.4 serial key or number
- First, download the Table v2.4 serial key or number
-
You can download its setup from given links:
Table v2.4 serial key or number & Serial Key Download
Table v2.4 serial key or number& Serial Key Download
Table v2.4 serial key or number
About Author
