Input to the OperationalCredentials addNoc command

MatterSpecification.v13.Core § 11.18.6.8

interface AddNocRequest {
    adminVendorId: VendorId;
    caseAdminSubject: NodeId;
    icacValue?: Uint8Array;
    ipkValue: Uint8Array;
    nocValue: Uint8Array;
}

Hierarchy (view full)

Properties

adminVendorId: VendorId = ...

This field shall be set to the Vendor ID of the entity issuing the AddNOC command. This value shall NOT be one of the reserved Vendor ID values defined in Table 1, “Vendor ID Allocations”.

If this command is received without an armed fail-safe context (see Section 11.10.6.2, “ArmFailSafe Command”), then this command shall fail with a FAILSAFE_REQUIRED status code sent back to the initiator.

If a prior UpdateNOC or AddNOC command was successfully executed within the fail-safe timer period, then this command shall fail with a CONSTRAINT_ERROR status code sent back to the initiator.

If the prior CSRRequest state that preceded AddNOC had the IsForUpdateNOC field indicated as true, then this command shall fail with a CONSTRAINT_ERROR status code sent back to the initiator.

If no prior AddTrustedRootCertificate command was successfully executed within the fail-safe timer period, then this command shall process an error by responding with a NOCResponse with a StatusCode of InvalidNOC as described in Section 11.18.6.7.2, “Handling Errors”. In other words, AddNOC always requires that the client provides the root of trust certificate within the same Fail- Safe context as the rest of the new fabric’s operational credentials, even if some other fabric already uses the exact same root of trust certificate.

If the NOC provided in the NOCValue encodes an Operational Identifier for a <Root Public Key, Fab

ricID> pair already present on the device, then the device shall process the error by responding with a StatusCode of FabricConflict as described in Section 11.18.6.7.2, “Handling Errors”.

If the device already has the CommissionedFabrics attribute equal to the SupportedFabrics attribute, then the device’s operational credentials table is considered full and the device shall process the error by responding with a StatusCode of TableFull as described in Section 11.18.6.7.2, “Handling Errors”.

If the CaseAdminSubject field is not a valid ACL subject in the context of AuthMode set to CASE, such as not being in either the Operational or CASE Authenticated Tag range, then the device shall process the error by responding with a StatusCode of InvalidAdminSubject as described in Section 11.18.6.7.2, “Handling Errors”.

Otherwise, the command is considered an addition of credentials, also known as "joining a fabric", and the following shall apply:

  1. A new FabricIndex shall be allocated, taking the next valid fabric-index value in monotonically incrementing order, wrapping around from 254 (0xFE) to 1, since value 0 is reserved and using 255 (0xFF) would prevent cluster specifications from using nullable fabric-idx fields.

  2. An entry within the Fabrics attribute table shall be added, reflecting the matter-fabric-id RDN within the NOC’s subject, along with the public key of the trusted root of the chain and the AdminVendorID field.

  3. The operational key pair associated with the incoming NOC from the NOCValue, and generated by the prior CSRRequest command, shall be recorded for subsequent use during CASE within the fail-safe timer period (see Section 5.5, “Commissioning Flows”).

  4. The incoming NOCValue and ICACValue (if present) shall be stored under the FabricIndex associated with the new Fabric Scope, along with the RootCACertificate provided with the prior successful AddTrustedRootCertificate command invoked in the same fail-safe period.

a. Implementation of certificate chain storage may separate or otherwise encode the components of the
   array in implementation-specific ways, as long as they follow the correct format when being read from
   the NOCs list or used within other protocols such as CASE.
  1. The NOCs list shall reflect the incoming NOC from the NOCValue field and ICAC from the ICACValue field (if present).

  2. The operational discovery service record shall immediately reflect the new Operational Identifier, such that the Node immediately begins to exist within the Fabric and becomes reachable over CASE under the new operational identity.

  3. The receiver shall create and add a new Access Control Entry using the CaseAdminSubject field to grant subsequent Administer access to an Administrator member of the new Fabric. It is recommended that the Administrator presented in CaseAdminSubject exist within the same entity that is currently invoking the AddNOC command, within another of the Fabrics of which it is a member.

  4. The incoming IPKValue shall be stored in the Fabric-scoped slot within the Group Key Management cluster (see KeySetWrite), for subsequent use during CASE.

  5. The Fabric Index associated with the armed fail-safe context (see Section 11.10.6.2, “ArmFailSafe Command”) shall be updated to match the Fabric Index just allocated.

  6. If the current secure session was established with PASE, the receiver shall:

a. Augment the secure session context with the FabricIndex generated above, such that subsequent
   interactions have the proper accessing fabric.
  1. If the current secure session was established with CASE, subsequent configuration of the newly installed Fabric requires the opening of a new CASE session from the Administrator from the Fabric just installed. This Administrator is the one listed in the CaseAdminSubject argument.

Thereafter, the Node shall respond with an NOCResponse with a StatusCode of OK and a FabricIndex field matching the FabricIndex under which the new Node Operational Certificate (NOC) is scoped.

MatterSpecification.v13.Core § 11.18.6.8.3

caseAdminSubject: NodeId = ...

If the AddNOC command succeeds according to the semantics of the following subsections, then the Access Control SubjectID shall be used to atomically add an Access Control Entry enabling that Subject to subsequently administer the Node whose operational identity is being added by this command.

The format of the new Access Control Entry, created from this, shall be:

NOTE

Unless such an Access Control Entry is added atomically as described here, there would be no way for the caller on its given Fabric to eventually add another Access Control Entry for CASE authentication mode, to enable the new Administrator to administer the device, since the Fabric Scoping of the Access Control List prevents the current Node from being able to write new entries scoped to that Fabric, if the session is established from CASE. While a session established from PASE does gain Fabric Scope of a newly-joined Fabric, this argument is made mandatory to provide symmetry between both types of session establishment, both of which need to eventually add an "Administer Node over CASE" Access Control Entry to finalize new Fabric configuration and subsequently be able to call the CommissioningComplete command.

MatterSpecification.v13.Core § 11.18.6.8.2

icacValue?: Uint8Array = ...
ipkValue: Uint8Array = ...

This field shall contain the value of the Epoch Key for the Identity Protection Key (IPK) to set for the Fabric which is to be added. This is needed to bootstrap a necessary configuration value for subsequent CASE to succeed. See Section 4.14.2.6.1, “Identity Protection Key (IPK)” for details.

The IPK shall be provided as an octet string of length CRYPTO_SYMMETRIC_KEY_LENGTH_BYTES.

On successful execution of the AddNOC command, the side-effect of having provided this field shall be equivalent to having done a GroupKeyManagement cluster KeySetWrite command invocation using the newly joined fabric as the accessing fabric and with the following argument fields (assuming KeySetWrite allowed a GroupKeySetID set to 0):

MatterSpecification.v13.Core § 11.18.6.8.1

nocValue: Uint8Array = ...