A networking device may provide several security services
and protocols like SSL, SSH, IPSec/IKE etc. which need
identities in the form of X509 certificates. The device
uses these certificates (called identity certificates) to
authenticate itself to various clients communicating with
the device using these protocols and also to provide other
protection for the communication like confidentiality,
integrity and non-repudiation. In addition, the device may
need to authenticate the clients which involves, among
other things, verifying the certificates presented by the
clients (peer certificates) during the protocol exchanges.
The certificate verification, in turn, involves the
certificate revocation status checking and the certificate signature verification. This MIB applies to the public key infrastructure (PKI) participation feature which enables a
networking device to participate in one or more PKI
services (also called Certificate Authorities) enabling
it to obtain one or more X509 identity certificates for
its own use as well as to verify peer certificates.
This MIB organizes the various certificates, key-pairs and Certificate Authority related information into the tables:
the trustpoint table for certificate and CA information
and a key-pair table for the key-pair information for each
type of key-pair such as RSA, DSA etc. An entry in the
trustpoint table corresponds to a trusted CA for obtaining
an identity certificate from and also for verifying the
peer certificates issued by that CA. The entry contains
information about the CA certificate, the identity
certificate - if obtained - from the CA, the corresponding
key-pair from a key-pair table (for which the identity
certificate was obtained) and the information needed for
revocation checking of certitifates issued by the CA.
For each type (RSA, DSA etc.) of key-pair supported by the
device, a key-pair table is present and contains an entry
for each key-pair of that type present in the device. This
allows future expansion of the MIB to support additional
key-pair types (currently only RSA key-pair is supported).
As seen above, a key-pair entry from a key-pair table can
be associated to an entry in the trustpoint table. A key-
pair entry can be associated to multiple trustpoint table
entries but not vice versa.
This MIB supports the certificate work-flow operations,
generally used for generating the key-pairs and obtaining
the certificates for them from various CAs. The following
are the steps in one typical work-flow:
1. create a trustpoint (an entry in trustpoint table) in
the device. 2. Authenticate a CA (this involves manually verifying the CA certificate/chain fingerprints and then inputing the CA certificate/chain into the trustpoint). 3. Generate a key-pair (an entry in key-pair table). 4. Associate the key-pair to the trustpoint. 5. Generate a pkcs#10 Certificate Signing Request (CSR) in the trustpoint. 7. Submit CSR to the CA and get the identity certificate. 9. Input the identity certificate into the trustpoint.
In another typical certificate work-flow, the key-pair and
the corresponding identity certificate are allowed to be
generated/obtained outside the device by whatever means
and then input to the device in the pkcs#12 form.
This MIB does not support the configuration of individual
security services like SSL, SSH, IPsec/IKE etc. to use
particular trustpoints or certificates and key-pairs in
them. Instead the security services certificate usage
configuration is supported in the respective feature MIBs.
Glossary of the terms used in this MIB: -------------------------------------- key-pair - A pair of public-key cryptographic keys in which one is public and the other private. RSA key-pair - A key-pair belonging to the RSA public-key cryptography algorithm. Certificate Authority (CA) - A service which issues X509 certificates to certify the identity (name) and public-key of end entities. X509 - A standard for certificates and CRLs. Reference: RFC 2459. CA certificate -
The self-signed certificate of a CA certifying its own
identity and public-key. CA certificate chain -
If a CA is certified by another CA which, in turn, was
certified by a third CA and so on, ending in a CA which
is self-certified, the original CA is said to be a
subordinate CA and its CA certificate is a chain which
is the set of CA certificates of all CAs involved. Identity certificate -
The certificate of a device issued by a CA in which the
device identity and public-key are certified. Trustpoint -
The various information about a CA (including its CA
certificate/chain), which the device wants to trust so
that it can use it to enroll with the CA to g et an
identity certificate and/or use it to verify the peer
certificates issed by the CA. Certificate fingerptint -
The digest of a certificate computed using MD5 or SHA
hash algorithm. CA authentication -
The process of configuring the CA certificate/chain for
a trustpoint. The process involves calculating the
fingerprints of the CA certificates and verifying them
against the same already published by the CAs. Enrollment - The process of creating a Certificate Signing Request in a trustpoint, submitting it to corresponding CA, getting
back the identity certificate and inputing it into the
trustpoint. Certificate verification -
The process of verifying the signature on a certificate
to see if it was really signed by the CA who issued it.
This verification process uses the CA certificate/chain. The certificate verification also involves verifying the
validity of certificate with respect to current time by
checking against the validity interval given in the
certificate and the revocation status of the certificate as maintained by the CA. Certificate Signing Request (CSR) - A request to a CA for signing a certificate of an entity.
The request contains the public key, the name and other
attributes of the entity. pkcs#10 - A standard syntax for the CSR, Reference: RFC 2986. pkcs#12 -
A standard for exporting and importing a certificate
along with associated key-pair and CA certificate/chain. Reference: PKCS #12 v1.0: Personal Information Exchange Syntax Standard, RSA Laboratories, June 24, 1999 CRL - Certificate Revocation List, a list of certificates that are revoked, as maintained by a CA. OCSP - Online Certificate Staus Protocol, a protocol for online checking of the revocation status of certificates. PEM format -
A printable text encoding format for certificates,
key-pairs and CRLs, as employed by the Privacy Enhanced Mail standard. Reference: RFCs 1421-1424.
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..64) · OCTET STRING · hint 255t
The unique name or label of key-pair.
cpkiRSAKeyPairId
1.3.6.1.4.1.9.9.505.1.1.1.1.2
Unsigned32
A unique identification nubmer of the RSA key-pair. This is included to support ordered lists of RSA key-pairs when needed. One such scenario where such ordered list may be needed is for per application configuration of key-pairs.
The size of the key.
The following modulus sizes are defined: 512-bit, 768-bit, 1024-bit, 1536-bit and 2048-bit. Once created, the size cannot be changed. After key-pair has been deleted through row deletion, the entry can be created again with another size.
cpkiRSAPvtKeyFileName
1.3.6.1.4.1.9.9.505.1.1.1.1.4
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
The name of the file storing the RSA private key. This filename is automatically generated from the key-pair name. It is a unix style '/' seperated string representing the absolute path of the file in the file system of the device
cpkiRSAKeyPairExportable
1.3.6.1.4.1.9.9.505.1.1.1.1.5
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
The key-pair is exportable through the 'exportpkcs12' PKI support action. Once created, the exportable flag value cannot be changed. After key-pair has been deleted through row deletion, the entry can be created again with another value for the exportable flag
cpkiRSAKeyPairStorageType
1.3.6.1.4.1.9.9.505.1.1.1.1.6
StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted.
If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.)
Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable. · Integer32
The storage type for this conceptual row.
cpkiRSAKeyPairConfigRowStatus
1.3.6.1.4.1.9.9.505.1.1.1.1.7
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
The conceptual row status of the key-pair entry. Deleting an entry through row delete will fail if the entry is being pointed to from an instance from cpkiTrustPointTable.
The objects in the entry may not be modified while the value of this object is active(1).
An attempt to set these objects while the value of cpkiRSAKeyPairConfigRowStatus is active(1) will result in an inconsistentValue error.
cpkiTrustPointTable
1.3.6.1.4.1.9.9.505.1.1.2
Index: cpkiTrustPointName
A list of trustpoint, associated key-pair, certificates and revocation checking configuration entries.
The table also provides control, actions, current operating state information and last action result information for the certificate work-flow if being carried out using the PKI support actions.
cpkiTrustPointName
1.3.6.1.4.1.9.9.505.1.1.2.1.1
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..64) · OCTET STRING · hint 255t
The unique name or label of a trustpoint.
cpkiTrustPointId
1.3.6.1.4.1.9.9.505.1.1.2.1.2
Unsigned32
A unique identification number of the trustpoint. This is included to support ordered lists of trustpoints when needed. One such scenario where such ordered list may be needed is for per application configuration of trustpoints for certificate selection
cpkiKeyPairName
1.3.6.1.4.1.9.9.505.1.1.2.1.3
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..64) · OCTET STRING · hint 255t
The name of the associated key-pair from a key-pair table. If a key-pair is not yet associated, the value of this object will be a zero length string.
If a key-pair is already associated, it can be modified only if the identity certificate is absent as indicated by a non-zero length string value of the object cpkiIssuerCertFileName. This is because of the fact that the identity certificate is certifying this key-pair.
cpkiIdCertFileName
1.3.6.1.4.1.9.9.505.1.1.2.1.4
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
The name of the file storing the identity certificate. It is a unix style '/' seperated string representing the absolute path of the file in the file system of the device. If there is no identity certificate obtained as yet, the value of this object will be a zero length string.
This object gets its non-zero length string value after a successful 'certimport' or 'pkcs12import' PKI support action triggered on the object cpkiAction.
This object gets set to zero length string when the identity certificate is deleted through a successful 'certdelete' action triggered on the object cpkiAction.
cpkiIdCertSubjectName
1.3.6.1.4.1.9.9.505.1.1.2.1.5
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
Reference: RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 4.1.2.6
The subject name of the identity certificate. If there is no certificate (as indicated by a zero length string value of the object cpkiIdCertFileName) or no subject name in the certificate, the value of this object will be a zero length string.
cpkiIdCertSerialNum
1.3.6.1.4.1.9.9.505.1.1.2.1.6
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
Reference: RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 4.1.2.2
The serial number of the identity certificate. If there is no certificate (as indicated by a zero length string value of the object cpkiIdCertFileName), the value of this object will be a zero length string.
cpkiIdCertStartDate
1.3.6.1.4.1.9.9.505.1.1.2.1.7
DateAndTimeA date-time specification.
field octets contents range
----- ------ -------- -----
1 1-2 year* 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC* 0..13
10 11 minutes from UTC 0..59
* Notes: - the value of year is in network-byte order - daylight saving time in New Zealand is +13
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone information (fields 8-10) is not present. SIZE (8 | 11) · OCTET STRING · hint 2d-1d-1d,1d:1d:1d.1d,1a1d:1d
Reference: RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 4.1.2.5
The time when the identity certificate starts to be valid, corresponding to the notBefore field in the certificate.
If there is no certificate (as indicated by a zero length string value of the object cpkiIdCertFileName), the value of this object will be a zero length string.
cpkiIdCertEndDate
1.3.6.1.4.1.9.9.505.1.1.2.1.8
DateAndTimeA date-time specification.
field octets contents range
----- ------ -------- -----
1 1-2 year* 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC* 0..13
10 11 minutes from UTC 0..59
* Notes: - the value of year is in network-byte order - daylight saving time in New Zealand is +13
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone information (fields 8-10) is not present. SIZE (8 | 11) · OCTET STRING · hint 2d-1d-1d,1d:1d:1d.1d,1a1d:1d
Reference: RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 4.1.2.5
The time when the identity certificate validity ends, corresponding to the notAfter field in the certificate.
If there is no certificate (as indicated by the zero length string value of the object cpkiIdCertFileName), the value of this object will be a zero length string.
cpkiIdCertFingerPrint
1.3.6.1.4.1.9.9.505.1.1.2.1.9
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
The MD5 fingerprint of the identity certificate in HEX string format.
If there is no certificate (as indicated by a zero length string value of the object cpkiIdCertFileName), the value of this object will be a zero length string.
cpkiIssuerCertFileName
1.3.6.1.4.1.9.9.505.1.1.2.1.10
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
The name of the file storing the issuer certificate. It is a unix style '/' seperated string representing the absolute path of the file in the file system of the device. If there is no issuer certificate obtained yet, the value of this object will be a zero length string.
This object gets its non-zero length string value after a successful 'caauth' PKI support action triggered on the object cpkiAction.
This object gets set to zero length string when the issuer certificate is deleted through a successful 'cadelete' action triggered on the object cpkiAction.
cpkiIssuerCertSubjectName
1.3.6.1.4.1.9.9.505.1.1.2.1.11
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
Reference: 1. RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 4.1.2.6 2. RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 5.1.2.3
The issuer name (subject name in issuer certificate which will be the same as the issuer name in the identity certificate if present).
If there is no certificate (as indicated by a zero length string value of the object cpkiIssuerCertFileName), the value will be a zero length string.
cpkiIssuerCertSerialNum
1.3.6.1.4.1.9.9.505.1.1.2.1.12
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
Reference: RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 4.1.2.2
The serial number of the issuer certificate.
If there is no certificate (as indicated by a zero length string value of the object cpkiIssuerCertFileName), the value will be a zero length string.
cpkiIssuerCertStartDate
1.3.6.1.4.1.9.9.505.1.1.2.1.13
DateAndTimeA date-time specification.
field octets contents range
----- ------ -------- -----
1 1-2 year* 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC* 0..13
10 11 minutes from UTC 0..59
* Notes: - the value of year is in network-byte order - daylight saving time in New Zealand is +13
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone information (fields 8-10) is not present. SIZE (8 | 11) · OCTET STRING · hint 2d-1d-1d,1d:1d:1d.1d,1a1d:1d
Reference: RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 4.1.2.5
The time when the issuer certificate starts to be valid, corresponding to the notBefore field in the certificate.
If there is no certificate (as indicated by a zero length string value of the object cpkiIssuerCertFileName), the value will be a zero length string.
cpkiIssuerCertEndDate
1.3.6.1.4.1.9.9.505.1.1.2.1.14
DateAndTimeA date-time specification.
field octets contents range
----- ------ -------- -----
1 1-2 year* 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC* 0..13
10 11 minutes from UTC 0..59
* Notes: - the value of year is in network-byte order - daylight saving time in New Zealand is +13
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone information (fields 8-10) is not present. SIZE (8 | 11) · OCTET STRING · hint 2d-1d-1d,1d:1d:1d.1d,1a1d:1d
Reference: RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Section 4.1.2.5
The time when the issuer certificate validity ends, corresponding to the notAfter field on in the certificate.
If there is no certificate (as indicated by a zero length string value of the object cpkiIssuerCertFileName), the value will be a zero length string.
cpkiIssuerCertFingerPrint
1.3.6.1.4.1.9.9.505.1.1.2.1.15
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
The MD5 fingerprint of the issuer's certificate in HEX string format.
If there is no certificate (as indicated by a zero length string value of cpkiIssuerCertFileName), the value of this object will be a zero length string.
cpkiRevokeCheckMethods
1.3.6.1.4.1.9.9.505.1.1.2.1.16
OCTET STRING SIZE (16)
Revocation checking methods list which is an ordered list of certificate revocation checking methods to be employed while verifying peer certificates issued by the CA corresponding to this trust point entry.
The value of this object is a ordered list of one or more 1-octet values, where each 1-octet value corresponds to a method in the revocation checking method enumeration:
none (1) - No revocation status checking needed;
instead consider the certificate as not revoked.
crl (2) - Use CRL for checking the revocation
status of certificates.
ocsp (3) - Use OCSP for checking the revocation
status of certificates.
If 'none' occures in the list, it should be the last value. The octets after the last value in the ordered list should be zero octets.
The order in which the revocation checking methods occur within the value of this object determines the order the revocation checking methods are attempted during the verification of a peer certificate.
The default value of this object (after row creation) contains only the revocation checking method 'crl'.
cpkiOCSPurl
1.3.6.1.4.1.9.9.505.1.1.2.1.17
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
The contact http url of the external OCSP server for certificate revocation checking using OCSP protocol.
The default value of this object (after row creation) is a zero length string
cpkiAction
1.3.6.1.4.1.9.9.505.1.1.2.1.18
CiscoPkiAction1 = noop2 = caauth3 = cadelete4 = certreq5 = certimport6 = certdelete7 = pkcs12import8 = pkcs12export9 = certconfirm10 = certnoconfirm11 = forcecertdelete12 = crlimport13 = crldeleteThe PKI Support Actions for performing the certificate work-flow operations.
'noop' - No operation
'caauth' - Certificate Authority (CA) authentication.
This operation is provided to authenticate a CA and install its CA certificate/chain in a trustpoint This action needs to be followed up with the 'certconfirm' or 'certnoconfirm' action explained below.
'cadelete' - CA Certificate/chain deletion. This
operation is provided to delete the CA certificate/chain from a trustpoint.
'certreq' - Identity certificate Request creation. This
operation is provided to generate a pkcs#10 format certificate request needed to obtain an identity certificate from a CA.
'certimport' - Identity certificate import. This operation is provided to install an identity certificate obtained from a CA for an earlier certificate request, in a trustpoint.
'certdelete' - Identity certificate deletion. This operation is provided to delete the identity certificate from a trustpoint. If the certificate is the only generic certificate in the device, delete is not allowed; 'forcecertdelete' operation needs to be used to force the delete.
'pkcs12import' - This operation is provided to facilitate the importing of the identity certificate, corresponding key-pair and CA certificate/chain in pkcs#12 format into a trustpoint.
'pkcs12export' - This operation is provided to facilitate the exporting of the key-pair, identity certificate and the CA certificate in pkcs#12format from a trustpoint.
'certconfirm' - This operation is provided to confirm the acceptability of a certificate after manual verification of its fingerprint subsequent to the action 'caauth', there by completing that action and installing the certificate in the trustpoint.
'certnoconfirm' - This operation is provided to confirm the unacceptability of a certificate after the manual verification of its fingerprint subsequent to the action 'caauth', there by rejecting the certificate and completing that action.
'forcecertdelete' - Same as 'certdelete' except it forces the delete.
'crlimport' - CRL import. This operation is provided to import a CRL into a trustpoint.
'crldelete' - CRL delete. This operation is provided to delete the CRL from a trustpoint. · Integer32
The PKI support action to be triggered for this trustpoint entry.
The PKI support actions are steps in the certificate work-flow used to facilitate the configuration of the RSAkey-pair, identity certificate and CA certificates in a trustpoint. A PKI support action is triggered by setting this object to the corresponding value as defined in TC CiscoPkiAction. The value of this object and the values of the objects cpkiActionUrl and cpkiActionPassword are interpreted and applied together as single action trigger. All thease actions operate over the trustpoint and modify appropriate columns in the entry.
An attempt to set this object when the value of the object cpkiActionResult is 'inProgress' will result in an inconsistentValue error.
The work-flow nature of certificate operations requires that the trustpoint entry already exists. Some of the operation requires that some other previous operations are already performed successfully, as seen below.
The following is a brief of each action semantics, its parameters and the result:
'caauth' - This action is used to authenticate a CA and configure its CA certificate/chain in this trustpoint. This is generally the first step in a certificate work-flow. It requires the parameter objects cpkiActionUrl and cpkiActionPassword set with appropriate values. The CA certificate/chain being installed should be available in PEM fromat in a file on bootflash. The filename is specified as 'bootflash:<filename>' as the value of the object cpkiActionUrl. On successful completion of the operation, the CA certificate fingerprint will be available as the value of the object cpkiIssuerCertFingerPrint and the value of the object cpkiLastActionResult will be 'needConfirm'. This action is to be followed up with a subsequent 'certconfirm' or 'certnoconfirm' as explained later, to complete the CA authentication process.
'cadelete' - This action is used to delete the CA certificate/chain from this trustpoint. On successful completion of the operation, the values of all issuer certificate related objects (cpkiIssuerCertFileName etc.) in this trustpoint entry will zero length strings. For this action to succeed, a CA certificate/chain should have been already configured through the 'caauth' action.
'certreq' - This action is used to generate a pkcs#10 certificate signing request (CSR) needed to obtain an identity certificate from the CA corresponding to this trustpoint entry. This entry should have a key-pair already associated (as indicated by non-zero value of cpkiKeyPairIndex in the entry). Also the CA certificate/ chain should have been already configured through the 'caauth' action. This action requires the parameter object cpkiActionPassword to be set with a password string which will be used as the 'challenge password' attribute in the CSR being created (the password being opional, it should be a zero length string if no password is being specified). On successful completion of the operation, the value of the object cpkiActionUrl will contain a file name string in the format 'bootflash:<filename>' which will contain the CSR generated in PEM format. This CSR has to be submitted to the CA to get the identity certificate. The process of submitting CSR to the CA and getting the identity certificate is a step not supported by this MIB currently. Once the identity certificate is obtained, it has to be installed in this trustpoint with a subsequent 'certimport' action explained next.
'certimport' - This action is used to import in this trustpoint, an idenetity certificate obtained from the corresponding CA for an earlier CSR generated (previous operation 'certreq'). It requires that the identity certificate being installed be available in PEM fromat in a
file on bootflash. The filename is specified as
'bootflash:<filename>' as the value of the object cpkiActionUrl. On successful completion of the operation, the values of all identity certificate related objects (cpkiIdCertFileName etc.) in this entry will get filled with the appropriate strings as per the corresponding attributes in the identity certificate.
'certdelete' - This action is used to delete the identity certificate from this trustpoint. On successful completion of the operation, the values of all identity certificate related objects (cpkiIdCertFileName etc.) in this entry will become zero length strings.
'pkcs12import' - This action is used to import the key-pair, identity certificate and the CA certificate/chain in pkcs#12 format into this trustpoint. It requires that the file containing the import data be available on bootflash and whose filename be specified as 'bootflash:<filename>' as the value of the object cpkiActionUrl. It also requires that the parameter object cpkiActionPassword to be set with a password string to be used for decoding the pkcs#12 data. On successful completion of the operation, an entry in the cpkiRSAKeyPairTable will be created corresponding to the imported key-pair and it will be named using the trustpoint name specified. Secondly, the values of all identity certificate related objects (cpkiIdCertFileName etc.) and the values of all issuer certificate related objects (cpkiIssuerCertFileName etc.)in this entry will get filled with the appropriate strings as per the corresponding attributes in the identity and CA certificates respectively.
'pkcs12export' - This action is used to export the key-pair, identity certificate and the CA certificate/chain in pkcs#12 format from this trustpoint. It requires that
the filename to contain the exported data be specified as
'bootflash:<filename>' as the value of the object cpkiActionUrl. It also requires that the parameter object cpkiActionPassword to be set with a password string to be used for encoding the pkcs#12 data. On successful completion of the operation, the exported data will be available on bootflash in the specified file.
'certconfirm' - This action is used to confirm as acceptable, the certificate fingerprint for the action 'caauth' in this trustpoint As mentioned earlier, the certificate fingerprint is available as the value of the object cpkiIssuerCertFingerPrint and the value of the object cpkiActionResult will be 'needConfirm' after a successfull 'caauth' action on a trustpoint. On successful completion of the 'certconfirm' operation, values of all issuer certificate related objects (cpkiIssuerCertFileName etc.) in this entry get filled with the appropriate strings as per the attributes in the CA certificate.
'certnoconfirm' - This action is used to confirm as not acceptable, the certificate fingerprint for the action 'caauth. As mentioned earlier, the certificate fingerprint is available as the value of the object cpkiIssuerCertFingerPrint and the value of the object cpkiActionResult will be 'needConfirm' after a successfull 'caauth' action on a trustpoint. On successful completion of the 'certnoconfirm' action subsequent to a 'caauth' action, the import pending CA certificate/chain will be rejected.
'forcecertdelete' - Same as 'certdelete' but the operation is forced even if the certificate being deleted is the last-most one.
'crlimport' - This action is used to import in this trustpoint, the CRL obtained from the corresponding CA. It requires that the CRL being imported be available in PEM fromat in a file on bootflash. The filename is specified as 'bootflash:<filename>' as the value of the object cpkiActionUrl. On successful completion of the operation, the CRL will be installed in the trustpoint. For this action to succeed, a CA certificate/chain should have been already configured through the 'caauth' action.
'crldelete' - This action is used to delete the CRL from a trustpoint. This action does not require any parameters.
On successful completion of any of the above actions, the result object cpkiActionResult will have the value 'success'. on any error during the execution of the action, the object cpkiActionResult will be set with the value 'failed' and the object cpkiActionFailureReason will have the appropriate failure message string.
An attempt to set this object with a value other than 'certconfirm' or 'certnoconfirm', when the value of the object cpkiActionResult is 'needConfirm', will result in an inconsistentValue error.
All Actions are done on existing entry, action trigger is not allowed as part of row creation.
Retrieving the value of this object via SNMP will always return 'noop'.
cpkiActionUrl
1.3.6.1.4.1.9.9.505.1.1.2.1.19
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
The value of this object indicates the filename containig the input or output certificate data needed for the PKI support action being triggered on this entry. The filename should pe specified as 'bootflash:<filename>' and it should be available on bootflash or get created on bootflash depending upon the action being triggered.
cpkiActionPassword
1.3.6.1.4.1.9.9.505.1.1.2.1.20
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..64) · OCTET STRING · hint 255t
The value of this object indicates the password required to perform the PKI support action being triggered. This password is required to be specified only for 'certreq', 'importpkcs12' and 'exportpkcs12' actions.
For security reasons, the value of this object, whenever it is retrieved by the management prototcol, is always the zero length string.
cpkiLastAction
1.3.6.1.4.1.9.9.505.1.1.2.1.21
CiscoPkiAction1 = noop2 = caauth3 = cadelete4 = certreq5 = certimport6 = certdelete7 = pkcs12import8 = pkcs12export9 = certconfirm10 = certnoconfirm11 = forcecertdelete12 = crlimport13 = crldeleteThe PKI Support Actions for performing the certificate work-flow operations.
'noop' - No operation
'caauth' - Certificate Authority (CA) authentication.
This operation is provided to authenticate a CA and install its CA certificate/chain in a trustpoint This action needs to be followed up with the 'certconfirm' or 'certnoconfirm' action explained below.
'cadelete' - CA Certificate/chain deletion. This
operation is provided to delete the CA certificate/chain from a trustpoint.
'certreq' - Identity certificate Request creation. This
operation is provided to generate a pkcs#10 format certificate request needed to obtain an identity certificate from a CA.
'certimport' - Identity certificate import. This operation is provided to install an identity certificate obtained from a CA for an earlier certificate request, in a trustpoint.
'certdelete' - Identity certificate deletion. This operation is provided to delete the identity certificate from a trustpoint. If the certificate is the only generic certificate in the device, delete is not allowed; 'forcecertdelete' operation needs to be used to force the delete.
'pkcs12import' - This operation is provided to facilitate the importing of the identity certificate, corresponding key-pair and CA certificate/chain in pkcs#12 format into a trustpoint.
'pkcs12export' - This operation is provided to facilitate the exporting of the key-pair, identity certificate and the CA certificate in pkcs#12format from a trustpoint.
'certconfirm' - This operation is provided to confirm the acceptability of a certificate after manual verification of its fingerprint subsequent to the action 'caauth', there by completing that action and installing the certificate in the trustpoint.
'certnoconfirm' - This operation is provided to confirm the unacceptability of a certificate after the manual verification of its fingerprint subsequent to the action 'caauth', there by rejecting the certificate and completing that action.
'forcecertdelete' - Same as 'certdelete' except it forces the delete.
'crlimport' - CRL import. This operation is provided to import a CRL into a trustpoint.
'crldelete' - CRL delete. This operation is provided to delete the CRL from a trustpoint. · Integer32
The PKI support action attempted last. In otherwords, the value attempted to be set for cpkiAction object last. If no action has been triggered for the trustpoint after its creation, then retrieving the value of this object will return 'noop'.
cpkiLastActionResult
1.3.6.1.4.1.9.9.505.1.1.2.1.22
CiscoPkiActionResult1 = none2 = success3 = failed4 = inProgress5 = needConfirmResult of the PKI Support action performed. An instance of this TC corresponds to an instance of the TC CpkiAction.
'none' - No action was performed yet.
'success' - Execution of the action triggered is
completed successfully.
'failed' - Execution of the action triggered has
failed.
'inProgress' - Execution of the action triggered is
in progress.
'needConfirm' - Further continuation of execution of
the action triggered requires confirmation from the user. · Integer32
The result of the execution of the last PKI support action (represented by the value of cpkiLastAction). When the value of this object is 'inProgress', an attempt to set the value of cpkiAction object will return inConsistentError.
cpkiLastActionFailureReason
1.3.6.1.4.1.9.9.505.1.1.2.1.23
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
The failure reason description for the failed execution of PKI support action. If the object cpkiActionResult has the value 'failed', then this object contains the reason string as to why it failed. Otherwise, the value of this object is a zero length string.
cpkiTrustPointStorageType
1.3.6.1.4.1.9.9.505.1.1.2.1.24
StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted.
If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.)
Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable. · Integer32
The storage type for this conceptual row.
cpkiTrustPointConfigRowStatus
1.3.6.1.4.1.9.9.505.1.1.2.1.25
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
The conceptual row status of the trustpoint entry.
After row creation, the value of this object will become active(1) as there is no prerequisite of certain objects to be set to make this object active.
The various read-only objects of the row can be populated only by means of the various PKI support actions attempted by setting the cpkiAction object with appropriate value.
Except the read-only objects mentioned, all other objects of the entry can be modified when the row is active subject to the restrictions, if any, specified for each