Version 1: Release Note 28 November 2014


Annex 3 – ASN.1 modules - informative



Download 4.8 Mb.
Page249/258
Date03.04.2021
Size4.8 Mb.
1   ...   245   246   247   248   249   250   251   252   ...   258

Annex 3 – ASN.1 modules - informative


This Annex collates all ASN.1 used in this GBCS. Please note that this is a duplicate; the authoritative content remains as documented in the appropriate section.

SetTime DEFINITIONS ::= BEGIN

CommandPayload ::= SEQUENCE

{

-- specify the period within which the Communications Hub’s time must lie



-- if this Command is successfully to set time

validityIntervalStart GeneralizedTime,

validityIntervalEnd GeneralizedTime

}

ResponsePayload ::= SEQUENCE



{

-- Specify the Device’s now current time

deviceTime GeneralizedTime,

-- Specify the Device’s now current Time Status

deviceTimeStatus DeviceTimeStatus

}

DeviceTimeStatus ::= INTEGER



{

reliable (0),

invalid (1),

unreliable (2)

}

END


ActivateFirmware DEFINITIONS ::= BEGIN

CommandPayload ::= SEQUENCE

{

-- specify the hash of the Manufacturer Image to be activated



manufacturerImageHash OCTET STRING,

-- the Originator Counter as in the Grouping Header of the Command

originatorCounter INTEGER (0..9223372036854775807),

-- the date-time at which the Command is to execute, if future dated

executionDateTime GeneralizedTime OPTIONAL

}

ResponsePayload ::= CHOICE



{

-- if the Command is future dated, the Response will not have any details of

-- execution (those will be in the subsequent alert)

commandAccepted NULL,

-- if the Command is for immediate execution, the Response will detail the

-- outcomes

executionOutcome ExecutionOutcome

}

AlertPayload ::= SEQUENCE



{

-- specify the Alert Code

alertCode INTEGER(0..4294967295),

-- specify the date-time of execution

executionDateTime GeneralizedTime,

-- the Originator Counter as in the Grouping Header of the corresponding Command

originatorCounter INTEGER (0..9223372036854775807),

-- detail what happened when the future dated command was executed

executionOutcome ExecutionOutcome

}

ExecutionOutcome ::= SEQUENCE



{

-- Specify whether the activation was successful or not

activateImageResponseCode ActivateImageResponseCode,

-- Specify the Device’s now current firmware version

firmwareVersion OCTET STRING

}

ActivateImageResponseCode::= INTEGER



{

success (0),

noImageHeld (1),

hashMismatch (2),

activationFailure (3)

}

END



ProvideSecurityCredentialDetails DEFINITIONS ::= BEGIN

Command ::= SEQUENCE

{

-- Identify which of the Public Keys on the Device is to be used in verifying the Signature or MAC



-- (so defining the nature of the verification by way of the KeyUsage parameter held on the

-- Device for the Public Key so identified).

authorisingRemotePartyTACellIdentifier TrustAnchorCellIdentifier,

-- List the Remote Party Role(s) for which credential details are required

remotePartyRolesCredentialsRequired SEQUENCE OF RemotePartyRole

}

Response ::= SEQUENCE OF RemotePartyDetails



RemotePartyDetails ::= SEQUENCE

{

-- Which Remote Party do these details relate to?



remotePartyRole RemotePartyRole,

-- statusCode shall be success unless the role is not valid on this type of Device or there is a processing failure

statusCode StatusCode,

-- What is the current Update Security Credentials Protection Against Replay number on the Device for this role, where there is such a number for this role?

currentSeqNumber SeqNumber OPTIONAL,

-- What are the details held on the Device for each of the Cells related to this role? The list shall have between one and

-- three entries (e.g. there will be one if role is transitional change of supplier; there may be three if role is supplier)

trustAnchorCellsDetails SEQUENCE OF TrustAnchorCellContents OPTIONAL

}

SeqNumber ::= INTEGER (0..9223372036854775807)



TrustAnchorCellContents ::= SEQUENCE

{

-- To what cryptographic use can the Public Key in this Cell be put? Some Remote Party Roles



-- (e.g. supplier) can have more than one Public Key on a Device and each one would only have

-- a single cryptographic use.

trustAnchorCellKeyUsage KeyUsage,

-- trustAnchorCellUsage is to allow for multiple Public Keys of the same keyUsage for the same Remote

-- Party Role. This will be absent except where used to refer to the Supplier Key Agreement Key.

-- This Key is used solely in relation to validating Supplier generated MACs on Prepayment Top Up transactions.

trustAnchorCellUsage CellUsage DEFAULT management,

-- The subjectUniqueID which shall be the 64 bit Entity Identifier of the Security Credentials in this Trust Anchor Cell.

existingSubjectUniqueID OCTET STRING,

-- The APKI requirements mean that KeyIdentifier attributes will all be 8 byte SHA-1 Hashes.

-- existingSubjectKeyIdentifier shall be set accordingly based on the contents of the Trust Anchor Cell

existingSubjectKeyIdentifier OCTET STRING

}

TrustAnchorCellIdentifier ::= SEQUENCE



{

-- Which Remote Party Role does this Cell relate to?

trustAnchorCellRemotePartyRole RemotePartyRole,

-- To what cryptographic use can the Public Key in this Cell be put? Some Remote Party Roles

-- (e.g. supplier) can have more than one Public Key on a Device and each one would only have

-- a single cryptographic use.

trustAnchorCellKeyUsage KeyUsage,

-- trustAnchorCellUsage is to allow for multiple Public Keys of the same keyUsage for the same Remote

-- Party Role. This may be absent except where use to refer to the Supplier Key

-- Agreement Key used solely in relation to validating Supplier generated MACs on Prepayment Top Up transactions

trustAnchorCellUsage CellUsage DEFAULT management

}

CellUsage ::= INTEGER {management(0), prePaymentTopUp(1)}



RemotePartyRole ::= INTEGER

{

-- Define the full set of Remote Party Roles in relation to which a Device may need to undertake



-- processing. Note that most Devices will only support processing in relation to a subset of these.

root (0),

recovery (1),

supplier (2),

networkOperator (3),

accessControlBroker (4),

transitionalCoS (5),

wanProvider (6),

issuingAuthority (7), -- Devices will receive such Certificates but they do not

-- need to store them over an extended period

-- The ‘other’ RemotePartyRole is for a party whose role does not allow it to invoke any Device function apart from

-- UpdateSecurityCredentials. This is to allow for Device functionality to be locked out of usage until a valid

-- Remote Party can be identified e.g. where roles cannot be fixed until a Device is bought in to operation

other (127)

}

-- KeyUsage is only repeated here for ease of reference. It is defined in RFC 5912



KeyUsage ::= BIT STRING

{

-- Define valid uses of Public Keys.



digitalSignature (0),

contentCommitment (1), -- not valid for GBCS compliant transactions

keyEncipherment (2), -- not valid for GBCS compliant transactions

dataEncipherment (3),

keyAgreement (4),

keyCertSign (5),

cRLSign (6),

encipherOnly (7),

decipherOnly (8) -- not valid for GBCS compliant transactions

}

-- The GBCS only allows for a constrained set of Trust Anchor Cell operations and so the list of possible outcomes



-- is more limited than in IETF RFC 5934. The list below is that more constrained subset

StatusCode ::= ENUMERATED {

success (0),

-- trustAnchorNotFound indicates that details of a trust anchor were requested, but the referenced trust anchor

-- is not represented on the Device

trustAnchorNotFound (25),

other (127)}

END


UpdateSecurityCredentials DEFINITIONS ::= BEGIN

CommandPayload ::= SEQUENCE

{

-- Provide details to allow the Device to identify the Remote Party Role authorising



-- this Command, check whether the rest of the payload is allowable, prevent replay attacks

-- and allow counters / counter caches on the Device to be reset, if the Command changes the Remote Party

-- in control.

-- The Remote Party authorising the Command is that party which generated the KRP Signature (or the Access Control Broker

-- if there is no KRP Signature)

authorisingRemotePartyControl AuthorisingRemotePartyControl,

-- One TrustAnchorReplacement structure is required for each Trust Anchor Cell that is to be updated

replacements SEQUENCE OF TrustAnchorReplacement,

-- Provide the certificates needed to undertake Certification Path Validation of the new

-- end entity certificate against the root public key held on the Device. The number of these may be less

-- than the number of replacement certificates (e.g. a supplier may replace all of its certificates but

-- may only need to supply one Certification Authority Certificate to link them all back to the root public

-- key as currently stored on the Device.

certificationPathCertificates SEQUENCE OF Certificate,

-- If the Command is to be future dated, specify the date-time at which the certificate replacement is to happen

executionDateTime GeneralizedTime OPTIONAL

}

ResponsePayload ::= SEQUENCE



{

-- if the Command is future dated, the Response will not have any details of execution (those will be in the subsequent alert)

commandAccepted NULL,

-- if the Command is for immediate execution, the Response will detail the outcomes

executionOutcome ExecutionOutcome OPTIONAL

}

AlertPayload ::= SEQUENCE



{

-- specify the Alert Code

alertCode INTEGER(0..4294967295),

-- specify the date-time of execution

executionDateTime GeneralizedTime,

-- detail what happened when the future dated Command was executed

executionOutcome ExecutionOutcome

}

ExecutionOutcome ::= SEQUENCE



{

-- Provide details of the corresponding Command that may not be in the standard GBCS message header. Specifically the

-- mode in which the Command was invoked, the Originator Counter in the original Command and the resulting changes to any

-- replay counters held on the Device

authorisingRemotePartySeqNumber SeqNumber,

credentialsReplacementMode CredentialsReplacementMode,

remotePartySeqNumberChanges SEQUENCE OF RemotePartySeqNumberChange,

-- For each replacement in the Command, detail the outcome and impacted parties

replacementOutcomes SEQUENCE OF ReplacementOutcome

}

AuthorisingRemotePartyControl ::= SEQUENCE



{

-- Specify the replacement mode so that the Device can check that the Remote Party Role is allowed to

-- authorise this type of replacement and that all replacements in the payload are allowed within this

-- replacement mode

credentialsReplacementMode CredentialsReplacementMode,

-- Only if credentialsReplacementMode = anyByContingency, provide the symmetric key to decrypt

-- the Contingency Public Key in the (root, digitalSignature, management) Trust Anchor Cell

plaintextSymmetricKey [0] IMPLICIT OCTET STRING OPTIONAL,

-- Specify whether the time based checks as part of any Certificate Path Validation should be applied

applyTimeBasedCPVChecks [1] IMPLICIT INTEGER {apply(0), disapply(1)} DEFAULT apply,

-- Identify which of the Public Keys on the Device is to be used in checking KRP Signature

-- ‘authorisingRemotePartyTACellIdentifier’ can only be omitted when

-- the access control broker is updating its own credentials. In all other cases it is mandatory.

authorisingRemotePartyTACellIdentifier [2] IMPLICIT TrustAnchorCellIdentifier OPTIONAL,

-- Specify the Originator Counter for the Remote Party Applying KRP Signature, or (for the

-- Access Control Broker changing its credentials) the Access Control Broker’s Originator Counter.

authorisingRemotePartySeqNumber [3] IMPLICIT SeqNumber,

-- If the Command is to effect a change of control, then newTrustAnchorFloorSeqNumber must be included

-- and will be the value used to prevent replay of Update Security Credentials Commands for the

-- new controlling Remote Party.

newRemotePartyFloorSeqNumber [4] IMPLICIT SeqNumber OPTIONAL,

-- Some Commands on the Device may use a different Originator Counter sequence for Protection Against Replay. At this

-- version of the GBCS, the only example is the Prepayment Top Up Command on ESME and GSME. The

-- SpecialistSeqNumber structure allows such Counters to also be reset on change of control.

newRemotePartySpecialistFloorSeqNumber [5] IMPLICIT SEQUENCE OF SpecialistSeqNumber OPTIONAL,

-- In some cases, one party acting in one Remote Party Role may be replacing certificates for a different Remote Party Role.

-- In some cases, sequence counters need also to be reset for those other Remote Party Role(s)

otherRemotePartySeqNumberChanges [6] IMPLICIT SEQUENCE OF RemotePartySeqNumberChange OPTIONAL

}

RemotePartySeqNumberChange ::= SEQUENCE



{

otherRemotePartyRole RemotePartyRole,

otherRemotePartyFloorSeqNumber SeqNumber,

newRemotePartySpecialistFloorSeqNumber SEQUENCE OF SpecialistSeqNumber OPTIONAL

}

SpecialistSeqNumber ::= SEQUENCE



{

-- Specify the usage of the SeqNumber

seqNumberUsage SeqNumberUsage,

-- Specify the associated SeqNumber

seqNumber SeqNumber

}

SeqNumberUsage ::= INTEGER



{

-- Define the full set of discrete usages on a Device. The only specialist

-- counter is for Prepayment Top Up (which is set independently of other counters). This may only be

-- included when changing Supplier Security Credentials on an ESME or GSME.

prepaymentTopUp (0)

}

SeqNumber ::= INTEGER (0..9223372036854775807)



TrustAnchorReplacement ::= SEQUENCE

{

-- Provide the new end entity certificate



replacementCertificate Certificate,

-- Specify where it is to go (specifically which Trust Anchor Cell is to have its details replaced using

-- the new end entity certificate)

targetTrustAnchorCell TrustAnchorCellIdentifier

}

ReplacementOutcome ::= SEQUENCE



{

affectedTrustAnchorCell TrustAnchorCellIdentifier,

statusCode StatusCode,

-- The GBCS Certificate requirements mean that the subjectUniqueID attribute in the subject field of a certificate will always

-- contain the 64 bit unique number that equates to Entity Identifier. existingSubjectUniqueID should be set

-- accordingly based on the contents of the Trust Anchor Cell prior to Command processing.

existingSubjectUniqueID OCTET STRING,

-- The GBCS Certificate requirements mean that subjectKeyIdentifier attributes will all be 8 byte SHA-1 Hashes.

-- existingSubjectKeyIdentifier should be set accordingly based on the contents of the Trust Anchor Cell prior to

-- Command processing.

existingSubjectKeyIdentifier OCTET STRING,

-- The subjectUniqueID in the subject field of the certificate in this TrustAnchorReplacement

replacingSubjectUniqueID OCTET STRING,

-- The subjectKeyIdentifier in the certificate in this TrustAnchorReplacement

replacingSubjectKeyIdentifier OCTET STRING

}

TrustAnchorCellIdentifier ::= SEQUENCE



{

-- Which Remote Party Role does this Cell relate to?

trustAnchorCellRemotePartyRole RemotePartyRole,

-- To what cryptographic use can the Public Key in this Cell be put? Some Remote Party Roles

-- (e.g. supplier) can have more than one Public Key on a Device and each one would only have

-- a single cryptographic use.

trustAnchorCellKeyUsage KeyUsage,

-- trustAnchorCellUsage is to allow for multiple Public Keys of the same keyUsage for the same Remote

-- Party Role. It will be absent except where used to refer to the Supplier Key

-- Agreement Key used solely in relation to validating Supplier generated MACs on Prepayment Top Up

-- transactions

trustAnchorCellUsage CellUsage DEFAULT management

}

CellUsage ::= INTEGER {management(0), prePaymentTopUp(1)}



RemotePartyRole ::= INTEGER

{

-- Define the full set of Remote Party Roles in relation to which a Device may need to undertake



-- processing. Note that most Devices will only support a subset of these.

root (0),

recovery (1),

supplier (2),

networkOperator (3),

accessControlBroker (4),

transitionalCoS (5),

wanProvider (6),

issuingAuthority (7), -- Devices will receive such Certificates but they do not need to store

-- them over an extended period

-- The ‘other’ RemotePartyRole is for a party whose role does not allow it to invoke any Device function apart from

-- UpdateSecurityCredentials. This is to allow for Device functionality to be locked out of usage until a valid

-- Remote Party can be identified e.g. where roles cannot be fixed until a Device is brought in to operation

other (127)

}

-- KeyUsage is only repeated here for clarity. It is defined in RFC 5912



KeyUsage ::= BIT STRING

{

-- Define valid uses of Public Keys held by Devices in their Trust Anchor Cells.



digitalSignature (0),

contentCommitment (1), -- not valid for GBCS compliant transactions

keyEncipherment (2), -- not valid for GBCS compliant transactions

dataEncipherment (3), -- not valid for GBCS compliant transactions

keyAgreement (4),

keyCertSign (5),

cRLSign (6),

encipherOnly (7), -- not valid for GBCS compliant transactions

decipherOnly (8) -- not valid for GBCS compliant transactions

}

CredentialsReplacementMode ::= INTEGER



{

-- Define the valid combinations as to which Remote Party Roles can replace which kinds of Trust Anchors.

-- Normal operational replacement modes

rootBySupplier (0),

rootByWanProvider (1),

supplierBySupplier (2),

networkOperatorByNetworkOperator (3),

accessControlBrokerByACB (4),

wanProviderByWanProvider (5),

transCoSByTransCoS (6),

supplierByTransCoS (7),

-- Recovery modes

anyExceptAbnormalRootByRecovery (8),

anyByContingency (9)

}

-- The GBCS only allows for a constrained set of Trust Anchor Cell operations and so the list of possible outcomes



-- is more limited than in RFC 5934. The list below is that more constrained subset

StatusCode ::= ENUMERATED {

success (0),

-- badCertificate is used to indicate that the syntax for one or more certificates is invalid.

badCertificate (5),

-- noTrustAnchor is used to indicate that the authorityKeyIdentifier does not identify the public key of a

-- trust anchor or a certification path that terminates with an installed trust anchor

noTrustAnchor (10),

-- insufficientMemory indicates that the update could not be processed because the Device did not

-- have sufficient memory

insufficientMemory (17),

-- contingencyPublicKeyDecrypt indicates that the update could not be processed because an error occurred while

-- decrypting the contingency public key.

contingencyPublicKeyDecrypt (22),

-- trustAnchorNotFound indicates that a change to a trust anchor was requested, but the referenced trust anchor

-- is not represented in the Trust Anchor Cell.

trustAnchorNotFound (25),

-- resourcesBusy indicates that the resources necessary to process the replacement are not available at the

-- present time, but the resources might be available at some point in the future.

resourcesBusy (30),

-- other indicates that the update could not be processed, but the reason is not covered by any of the assigned

-- status codes. Use of this status code SHOULD be avoided.

other (127) }

END


IssueSecurityCredentials DEFINITIONS ::= BEGIN

CommandPayload ::= SEQUENCE

{

-- specify the keyUsage to which the generated key-pair will be put, if subsequently authorised



keyUsage KeyUsage

}

ResponsePayload ::= CHOICE



{

-- if the Command was successful, provide the generated Certification Request. CertificationRequest shall

-- be as defined in ASN.1 by IETF RFC 5912. For reference, it is in the section headed ‘ASN.1 Module for RFC 2986’

certificationRequest CertificationRequest,

-- if the Command was unsuccessful, detail the failure

issueCredentialsResponseCode IssueCredentialsResponseCode

}

-- KeyUsage is only repeated here for ease of reference. It is defined in IETF RFC 5912



KeyUsage ::= BIT STRING

{

-- Define valid uses of Public Keys held by Devices in their Trust Anchor Cells.



digitalSignature (0),

contentCommitment (1), -- not valid for GBCS compliant transactions

keyEncipherment (2), -- not valid for GBCS compliant transactions

dataEncipherment (3), -- not valid for GBCS compliant transactions

keyAgreement (4),

keyCertSign (5), -- not valid for this Use Case

cRLSign (6), -- not valid for this Use Case

encipherOnly (7), -- not valid for GBCS compliant transactions

decipherOnly (8) -- not valid for GBCS compliant transactions

}

IssueCredentialsResponseCode::= INTEGER



{

invalidKeyUsage (1),

keyPairGenerationFailed (2),

cRProductionFailed (3)

}

END


UpdateDeviceCertificateonDevice DEFINITIONS ::= BEGIN

CommandPayload ::= Certificate

-- provide the certificate which the Device is to store

-- the ASN.1 specification of certificate shall be as defined in IETF RFC 5912 for IETF RFC 5280

ResponsePayload ::= UpdateDeviceCertResponseCode

-- if the Command was unsuccessful, detail the failure; otherwise respond with success

UpdateDeviceCertResponseCode::= INTEGER

{

success (0),



invalidCertificate (1),

wrongDeviceIdentity (2),

invalidKeyUsage (3),

noCorrespondingKeyPairGenerated (4),

wrongPublicKey (5),

certificateStorageFailed (6),

privateKeyChangeFailed (7)

}

END



ProvideDeviceCertificateFromDevice DEFINITIONS ::= BEGIN

CommandPayload ::= SEQUENCE

{

-- specify the KeyUsage of the Certificate to be returned



keyUsage KeyUsage

}

ResponsePayload ::= CHOICE



{

-- if the Command was successful, provide the certificate

certificate Certificate,

-- if the Command was unsuccessful, detail the failure

provideDeviceCertResponseCode ProvideDeviceCertResponseCode

}

-- KeyUsage is only repeated here for ease of reference. It is defined in RFC 5912



KeyUsage ::= BIT STRING

{

-- Define valid uses of Public Keys held by Devices in their Trust Anchor Cells.



digitalSignature (0),

contentCommitment (1), -- not valid for GBCS compliant transactions

keyEncipherment (2), -- not valid for GBCS compliant transactions

dataEncipherment (3), -- not valid for GBCS compliant transactions

keyAgreement (4),

keyCertSign (5), -- not valid for this Use Case

cRLSign (6), -- not valid for this Use Case

encipherOnly (7), -- not valid for GBCS compliant transactions

decipherOnly (8) -- not valid for GBCS compliant transactions

}

ProvideDeviceCertResponseCode::= INTEGER



{

invalidKeyUsage (1),

noCertificateHeld (2),

certificateRetrievalFailure (3)

}

END


JoinDevice DEFINITIONS ::= BEGIN

CommandPayload ::= SEQUENCE

{

-- specify which type of joining is being authorised and,



-- for Method A Joins, the role the Device is to play

joinMethodAndRole JoinMethodAndRole,

-- specify the Entity Identifier of the Device which is to be Joined with

otherDeviceEntityIdentifier OCTET STRING,

-- specify the DeviceType of that other Device

otherDeviceType DeviceType,

-- provide the other Device’s Key Agreement certificate, if and only if this

-- is a join between a gSME and a type1PrepaymentInterfaceDevice.

-- Certificate shall be as defined in IETF RFC 5912

otherDeviceCertificate Certificate OPTIONAL

}

-- detail whether the Command successful executed or, if it didn’t,



-- what the failure reason was

ResponsePayload ::= JoinResponseCode

JoinMethodAndRole ::= INTEGER

{

-- methodB is to be used where the other Device is a Type 2 Device or GPF.



-- methodC is used where the Devices involved are a GSME and a PPMID.

-- methodA is used otherwise.

-- methodAInitiator is used where the Device this Command is targeted at

-- should initiate the Key Agreement process

-- methodAResponder is used where the Device this Command is targeted at

-- should respond in the Key Agreement process, but shall not initiate it

methodAInitiator (0),

methodAResponder (1),

methodB (2),

methodC (3)

}

DeviceType ::= INTEGER



{

gSME (0),

eSME (1),

communicationsHubCommunicationsHubFunction (2),

communicationsHubGasProxyFunction (3),

type1HANConnectedAuxiliaryLoadControlSwitch (4),

type1PrepaymentInterfaceDevice (5),

type2 (6)

}

JoinResponseCode::= INTEGER



{

success (0),

invalidMessageCodeForJoinMethodAndRole (1),

invalidJoinMethodAndRole (2),

incompatibleWithExistingEntry (3),

deviceLogFull (4),

writeFailure (5),

keyAgreementNoResources (6),

keyAgreementUnknownIssuer (7),

keyAgreementUnsupportedSuite (8),

keyAgreementBadMessage (9),

keyAgreementBadKeyConfirm (10),

invalidOrMissingCertificate (11)

}

END



UnjoinDevice DEFINITIONS ::= BEGIN

CommandPayload ::= OtherDeviceEntityIdentifier

-- specify the Entity Identifier of the Device for which authorisation

-- is to be removed

OtherDeviceEntityIdentifier ::= OCTET STRING

ResponsePayload ::= UnjoinResponseCode

-- detail whether the Command successful executed or, if it didn’t,

-- what the failure reason was

UnjoinResponseCode::= INTEGER

{

success (0),



otherDeviceNotInDeviceLog (1),

otherFailure (2)

}

END


ReadDeviceLog DEFINITIONS ::= BEGIN

CommandPayload ::= NULL

ResponsePayload ::= SEQUENCE

{

-- detail whether the Command successful



readLogResponseCode ReadLogResponseCode,

-- if it was, return the Log Entries

deviceLogEntries SEQUENCE OF DeviceLogEntry OPTIONAL

}

DeviceLogEntry ::= SEQUENCE



{

deviceIndentifier OCTET STRING,

deviceType DeviceType

}

DeviceType ::= INTEGER



{

gSME (0),

eSME (1),

communicationsHubCommunicationsHubFunction (2),

communicationsHubGasProxyFunction (3),

type1HANConnectedAuxiliaryLoadControlSwitch (4),

type1PrepaymentInterfaceDevice (5),

type2 (6)

}

ReadLogResponseCode::= INTEGER



{

success (0),

readFailure (1)

}

END



GPFDeviceLog DEFINITIONS ::= BEGIN

BackupAlertPayload ::= SEQUENCE

{

-- specify the Alert Code



alertCode INTEGER(0..4294967295),

-- specify the date-time of the backup

backupDateTime GeneralizedTime,

-- detail the entries in the Device Log now that the change has been made

deviceLogEntries SEQUENCE OF DeviceLogEntry

}

RestoreCommandPayload ::= SEQUENCE



{

-- list the Device Log entries that are to be added

deviceLogEntries SEQUENCE OF DeviceLogEntry

}

DeviceLogEntry ::= SEQUENCE



{

-- specify the Entity Identifier of the Device

deviceEntityIdentifier OCTET STRING,

-- specify the DeviceType of that Device

deviceType DeviceType

}

RestoreResponsePayload ::= SEQUENCE



{

-- for each DeviceLog Entry, detail whether the Command successfully executed or, if it didn’t, what the failure reason was

restoreOutcomes SEQUENCE OF RestoreOutcome

}

RestoreOutcome ::= SEQUENCE



{

deviceLogEntry DeviceLogEntry,

joinResponseCode JoinResponseCode

}

DeviceType ::= INTEGER



{

gSME (0),

eSME (1),

communicationsHubCommunicationsHubFunction (2),

communicationsHubGasProxyFunction (3),

type1HANConnectedAuxiliaryLoadControlSwitch (4),

type1PrepaymentInterfaceDevice (5),

type2 (6)

}

JoinResponseCode::= INTEGER



{

success (0),

invalidMessageCodeForJoinMethodAndRole (1),

invalidJoinMethodAndRole (2),

incompatibleWithExistingEntry (3),

deviceLogFull (4),

writeFailure (5),

keyAgreementNoResources (6),

keyAgreementUnknownIssuer (7),

keyAgreementUnsupportedSuite (8),

keyAgreementBadMessage (9),

keyAgreementBadKeyConfirm (10),

invalidOrMissingCertificate (11)

}

END



  1. Directory: government -> uploads -> system -> uploads -> attachment data -> file
    file -> Remove this if sending to pagerunnerr Page Title Light Rail Security Recommended Best Practice
    file -> 8 Section 1 : Sport
    file -> Notice of exercise of additional powers of seizure under Sections 50 or 51 of the Criminal Justice and Police Act 2001
    file -> Home office circular 004/2014 Powers to search for and seize invalid travel documents in Schedule 8 to the Anti-social Behaviour, Crime and Policing Act 2014
    file -> Consultation on the Royal Parks and Other Open Spaces (Amendment) (No. 2) Regulations 2012
    file -> Crown copyright 2012
    file -> This is the Report to Government by the Film Policy Review Panel The brief
    file -> Impact Assessment (IA)
    file -> Dcms/Wolfson Museums and Galleries Improvement Fund a public-Private Partnership (2002-2010)


    Share with your friends:
1   ...   245   246   247   248   249   250   251   252   ...   258




The database is protected by copyright ©essaydocs.org 2020
send message

    Main page