< 上一个 | 内容 | 下一个 >

‌6.11 Certificate management‌

6.11.1 Introduction

This standard defines a public key infrastructure (PKI) in the IEEE 2030.5 certificate management system: the Manufacturing PKI. The Manufacturing PKI issues certificates to devices at the time of application installation (e.g., at manufacture). These certificates are intended for use during deployment (or redeployment) and on-going operation to authenticate the device to other IEEE 2030.5 devices implementing IEEE 2030.5 applications over TLS. It is expected that the market will implement one or more Manufacturing PKIs in accordance with the requirements set forth in this standard.

In addition, this document describes a few other types of certificates that IEEE 2030.5 applications may encounter depending on which services they support—see 6.11.8.4. While native IEEE 2030.5 devices are required to understand, support, and process Manufacturing PKI certificates, support of the additional

certificates is optional and generally targeted at specific classes of devices (e.g., energy services interface [ESI], web portal).

There are six classes of certificates that may be active in an IEEE 2030.5 system, depending on configuration and use, as follows:

 Device certificates: Issued under the Manufacturing PKI during manufacturing to purpose-built (aka “native”) IEEE 2030.5 certified devices for operational purposes.

 Device test certificates: Issued under the Manufacturing PKI during manufacturing to purpose-built (aka “native”) IEEE 2030.5 certified devices for test purposes.

 Additional certificates for IEEE 2030.5 devices: One or more OPTIONAL TLS server certificates issued by non-IEEE 2030.5 CAs to IEEE 2030.5 devices such as ESIs for use in addition to the device certificate.

 Generic client certificate for non-native entities: A TLS client certificate issued by a generic (non- IEEE 2030.5) certificate authority to a non-native entity.

 Generic server certificate for non-native entities: A TLS server certificate issued by a generic (non- IEEE 2030.5) certificate authority to a non-native entity.

 Self-signed client certificate for non-native entities: A TLS client certificate self-generated and self- signed by a customer or software.

6.11.2 Certificate usage—authentication versus authorization

Certificates provide a mechanism to authenticate an identity. Once authenticated (by proving possession of the associated private key, and by having the certificate chain to a known root of trust), that identity (or the service, person, or application associated with that identity) can be authorized access to resources, the ability to assume a role (e.g., system operator, general user), or perform various functions.

An authenticated certificate by itself does not generally grant authorization. Specific applications that accept the certificate MAY grant implicit authorization to access any resource under the purview of the application, but usually authorize access based on the identity represented by the certificate (e.g., an access control list entry). The following tables describe both the authentication and authorization uses of certificates described by this profile.

Table 14 describes the mechanisms for certificate validation—the authentication of the identity claimed in the certificate. Note that for a self-signed certificate, the authentication is limited only to validating the self- signature over the certificate and that provides only an integrity check.

The phrase “IEEE 2030.5 Cert - Indef” is meant to convey that Manufacturing PKI certificates are indefinitely valid and the check is limited solely to a check of the signatures on the certificate chain. The phrase “Optional OCSP” means that the server device (and optionally, the client device) may utilize Online Certificate Status Protocol (OCSP) (IETF RFC 6960) as an additional mechanism to determine if a certificate has been revoked. OCSP may only be used to verify non-IEEE 2030.5 certificates.

Table 15 describes the mechanisms for determining if the holder of a specific certificate (and its private key) may access specific resources. Generically, each resource has an ACL tagged to it. If the identity of the certificate holder has the appropriate rights to a specific resource, then the representation of the resource is returned via query. Note that there are certain resources that are accessible to all authenticated clients.

‌Table 14 —TLS authentication matrix

Table 14 should be read as describing the authentication on the offered client certificate by the server. For example, Generic client/Native IEEE 2030.5 application has an “Optional OCSP” entry meaning the IEEE 2030.5 Application can OPTIONALLY use OCSP to check the validity of the Generic Client certificate in addition to its normal certificate validation process.

“IEEE 2030.5 Cert - Indef” means that if the IEEE 2030.5 Manufacturing PKI certificate validly chains to the IEEE 2030.5 root it is considered valid—neither OCSP nor CRLs are used or issued by CAs within the Manufacturing PKI hierarchy.

‌Table 15 —IEEE 2030.5 authorization matrix

The above table should be read as describing the authorization mechanism used by the server with respect to the offered client credential. For example, the Generic Client/Native IEEE 2030.5 application entry of “ACL” means that either there is a specific ACL for the generic client credential that permits access to specific data, or the absence of such ACL allows that generic client access only to public resources.

6.11.3 Manufacturing PKI

6.11.3.1 Introduction

This subclause covers only those certificates issued under the auspices of the Manufacturing PKI. It specifically excludes the certificates described in 6.11.8.4 as “Other Certificates.”

Any IEEE 2030.5 Manufacturing PKI SHOULD be a hierarchy with a depth of 2, 3, or 4 levels. At the top level, Manufacturing PKI hierarchy SHOULD have one SERCA. A commercial CA MAY operate one or more SERCAs as business needs dictate, and this is one possible model for the initial operation of the SERCAs. Private key material for a SERCA SHOULD be held in a form to allow secure transfer of the material to a new commercial CA if necessary. The SERCA issues MCA certificates and MICA certificates to authorized vendors.

A SERCA MAY issue device certificates on behalf of one or more manufacturers.

The Manufacturing PKI hierarchy MAY include one IEEE 2030.5 MCA. One or more MCAs SHOULD be out-sourced to an IEEE 2030.5 vendor, specifically for the issuance of vendor-specific MICAs. An IEEE

2030.5 vendor MAY contract with a commercial CA to host the IEEE 2030.5 vendor’s MCA credentials (certificate and private key), but retains ownership of such credentials. MCAs may only issue MICA certificates.

The Manufacturing PKI hierarchy MAY include one IEEE 2030.5 MICA. One or more MICAs SHOULD be out-sourced to an IEEE 2030.5 vendor, specifically for the production of IEEE 2030.5 certified devices by that vendor.

All devices SHALL store exactly one SERCA in their certificate path. All devices SHALL include at least the public keys of all existing SERCAs and MAY include their certificates. In the course of any particular authentication, any device can therefore verify the chain of signatures leading up to any one of the roots.

The following certificate paths are the only valid instantiations of the Manufacturing PKI:

 SERCA > device certificate

 SERCA > MICA > device certificate

 SERCA > MCA > MICA > device certificate

6.11.3.2 Manufacturing certificate lifecycle

Certificates within the Manufacturing PKI have an indefinite lifetime—this includes, specifically, a SERCA. Nevertheless, CA certificates may be retired and subsequently replaced when circumstances dictate. In such cases, the retired certificate and its associated private key SHALL no longer be used for issuing certificates. However, parties MAY continue to rely on those certificates for validating subordinate certificates. If, however, the signature algorithm or parameter set used in a manufacturing certificate comes to be viewed as insufficiently secure for the purpose, parties MAY retire those certificates and associated public keys. A retired certificate and key may no longer be used for issuing new certificates, but is not considered revoked for the purpose of validation.

An MCA or MICA certificate SHALL NOT be re-issued (e.g., re-signed with the same SubjectName and public key, but with a new validity period). Instead, if it is desired to retire an existing key/certificate, a new key pair SHALL be generated and bound into a new MCA or MICA certificate generally with a new serialNumber component of the SubjectName. Operationally, the responsible CA SHOULD verifiably destroy9 the private key of the retired certificate. Retired certificates MUST remain available to verify subsidiary certificates. A replacement of a MCA or MICA SHOULD use a new name formed by incrementing or otherwise adjusting the serialNumber component of the subject name. See 6.11.8.3.1 and

6.11.8.3.2 for the format of the name.

A side effect of the indefinite lifetime requirement coupled with the permanent embedding of the device certificate and its certificate chain within a device is that the device, MCA, and MICA certificates MUST NOT and cannot be revoked once issued. Specifically, no MCA, MICA, or SERCA shall issue or be required to issue CRLs, and no MCA or MICA shall operate or have operated on their behalf any OCSP server for the purpose of providing validity information for any certificate under the Manufacturing PKI hierarchy. This does not preclude the use of a certificate and its corresponding identity to be used in a blacklist or whitelist for authorization purposes to allow or deny access to resources on a server.

‌9 The process for destroying private keys is a business issue that should be covered by any contract for SERCA services.

6.11.3.3 Device certificate lifetime

NIST SP800-57 treats the question of the expected lifetime of various algorithm choices and key lengths. For the purpose of this document, the Manufacturing PKI certificate uses a choice for algorithm and key length that currently have no end-use date.

6.11.3.4 Device certificate validity

A device certificate issued by the Manufacturing PKI is considered valid indefinitely. However, the validity of the certificate does not imply any authorizations for the holder of the certificate. Any relying party is responsible for maintaining a mechanism for determining whether a given certificate is usable (e.g., valid authenticator for specific resource, implicit authorization) in a given circumstance (e.g., an access control list or other white or black list).

‌6.11.4 General certificate format

6.11.4.1 RFC 5280 compliance

All certificates in the Manufacturing PKI SHALL be compliant with IETF RFC 5280.

6.11.4.2 IEEE 802.1AR compliance

Device certificates and device test certificates in the Manufacturing PKI SHALL be compliant with IEEE Std 802.1AR™ with the following exceptions:

 Device certificates and device test certificates take the general form of an iDevID certificate as defined in IEEE Std 802.1AR.

 Differing from IEEE Std 802.1AR requirements, the SubjectName field of the device certificate is empty as the X500 name form is not well suited to describe or identify physical serialized devices.10 The device identity is contained in the SubjectAlternativeName extension which contains a single GeneralName of type OtherName that is further sub-typed as a HardwareModuleName (id-on-HardwareModuleName) as defined in IETF RFC 4108. Per IETF RFC 5280, this extension MUST be marked critical when the SubjectName field is empty. The hwType field of HardwareModule name is assigned by the IEEE 2030.5 manufacturer and SHOULD be different for each different type of manufactured device.

6.11.5 General restrictions and conditions

In addition, IEEE 2030.5 certificates have the following restrictions:

 All IEEE 2030.5 certificates are X.509 v3 certificates as defined in IETF RFC 5280.

 The only permitted public key type for IEEE 2030.5 certificates in the Manufacturing PKI is an Elliptic Curve (EC) public key on the NIST P-256 curve. (See 6.11.8.4.4 and 6.11.8.4.5 for details on the use of RSA Public Keys and certificates.)

‌10 Or rather there are too many different possible ways to represent these types of entities using X500 Distinguished Names. Rather than attempt to resolve the differences between each individual company’s interpretation of SubjectName guidance in IEEE Std 802.1AR, we constrain the identity expression to just the SubjectAlternativeName format described in IEEE Std 802.1AR.

 The signature method for signatures formed by EC P-256 private keys MUST be SHA256withECDSA.

 Within the Manufacturing PKI hierarchy, all certificates MUST contain only an EC P-256 public key. That public key MUST contain an elliptic curve point in uncompressed form. See IETF RFC 5480 Section 2.2 for details on the uncompressed form.

 Per IETF RFC 5280, CAs MUST ensure the uniqueness of the serial numbers on the certificates they issue. CAs MAY use one of three mechanisms to meet this requirement: comparison against previously issued certificates, monotonically increasing serial numbers, or random octet string. For the latter method, true random strings of 8 octets are sufficient for certificates issued by SERCAs or by MCAs, random strings of 10 octets are sufficient for certificates issued by MICAs that are planning to issue less than 50 million certificates, and 11 octets are sufficient for MICAs that are planning to issue less than 250 million certificates.11

 Per IETF RFC 5280, the IssuerName of any certificate MUST be identical to the signer’s SubjectName.

 With the exception of device certificates and device test certificates as described in 6.11.8.3.3 and 6.11.8.3.4, the SubjectName MUST be non-empty.

‌6.11.6 Extensions

IEEE 2030.5 certificate extensions have the following restrictions:

 The certificatePolicy extension in any certificate consists of one or more PolicyInformation objects containing only the policyIdentifier field. The PolicyInformation object MUST NOT contain any policyQualifier fields. If present, the policyQualifier field SHOULD be ignored.

 In the Manufacturing PKI hierarchy, each device certificate and the CAs that make up the device certificate’s path contain one or more device type identifiers encoded in the certificatePolicy extension in the PolicyInformation: policyIdentifier field. These policyIdentifier Object Identifiers (OIDs) (IETF RFC 5280) are taken from those OIDs defined under the deviceType arc of the IEEE 2030.5 OID tree. See 6.11.7.2 below for acceptable values and for information on the management of that arc.

 Each certificate in the Manufacturing PKI hierarchy MUST have a Valid:notBefore field consisting of the time of issue encoded as per IETF RFC 5280 Section 4.1.2.5 and a Valid:notAfter field consisting of the GeneralizedTime value 99991231235959Z (see IETF RFC 5280, Section 4.1.2.5) for 256-bit ECC-based certificates.

 Each CA certificate MUST contain a SubjectKeyIdentifier extension with an 8-octet key identifier generated as per method (2) of Section 4.2.1.2 of IETF RFC 5280. A non-CA certificate MAY contain a SubjectKeyIdentifier extension—if it does, such extension MUST be generated as per method 2 of Section 4.2.1.2 of IETF RFC 5280. In both cases, the extension MUST be marked non-critical.

 IEEE 2030.5 devices MUST be able to follow a chain where the key identifier was not generated in compliance with this subclause, but where there is correspondence in actual values between a child AuthorityKeyIdentifier and a parent’s (CA’s) SubjectKeyIdentifier.

 Each certificate, except self-signed client certificates and root certificates, MUST contain an AuthorityKeyIdentifier extension of form [0] KeyIdentifier where the value of the KeyIdentifier field is taken from the value of the SubjectKeyIdentifier extension of the certificate issuer. The extension MUST be marked non-critical.

‌11 This is derived from the birthday collision problem where we want to set the chance of collision in the random space at less than

108. 8 octets  600 000 certs, 10 octets  155 106 certs, 11 octets  2.5 109 certs signed without serial number collision.

6.11.7 Additional ASN1 definitions

6.11.7.1 Introduction

The IEEE 2030.5 object identifier arc has been allocated by the IANA as follows:

ieee2030.5 OBJECT IDENTIFIER ::= { iso(1) identified-organizations(3) dod(6) internet(1) private(4) enterprise(1) 40732 }

‌6.11.7.2 IEEE 2030.5 device type assignments

The deviceType is included in the CertificatePolicy extension of the device certificate and its issuing chain of CA certificates. It may be used for authorization purposes as described in 6.2.3.4.4.

deviceType OBJECT IDENTIFER ::= { ieee2030.5 1 }

id-IEEE 2030.5-dev-genericIEEE 2030.5Device OBJECT IDENTIFIER ::= { deviceType 1 }

-- used for most devices

id-IEEE 2030.5-dev-mobile OBJECT IDENTIFIER ::= { deviceType 2 }

-- used in addition to genericIEEE 2030.5Device to identify "mobile" IEEE 2030.5

-- entities (may be homed to multiple ESI domains)

id-IEEE 2030.5-dev-postManufactureIEEE 2030.5 OBJECT IDENTIFIER ::= { deviceType 3 }

-- used in device certs issued post-manufacture

6.11.7.3 IEEE 2030.5 policy assignments

One or more of IEEE 2030.5 Policy OIDS MAY be included in the device certificate and its issuing chain of CA certificates.

IEEE 2030.5 Policy OBJECT IDENTIFIER ::== { ieee2030.5 2 }

id-IEEE 2030.5-po-device-auth-test OBJECT IDENTIFIER ::= { IEEE 2030.5 Policy 1 }

-- MUST be included in test certificates

id-IEEE 2030.5-po-selfsigned-client OBJECT IDENTIFIER ::= { IEEE 2030.5 Policy 2 }

-- MUST be included in IEEE 2030.5 self-signed certificates

id-IEEE 2030.5-po-service-provider OBJECT IDENTIFIER ::= { IEEE 2030.5 Policy 3 }

-- MUST be included in commercial certificates issued to

-- service providers for IEEE 2030.5 purposes.

Id-IEEE 2030.5-po-bulk-cert OBJECT IDENTIFIER ::= { IEEE 2030.5 Policy 4 }

-- MUST be included in bulk-issued certificates (e.g.,

-- where the private key is generated off the device by the

‌-- issuing CA

6.11.7.4 HardwareModuleName

Excerpted from IETF RFC 4108:

id-on-hardwareModuleName OBJECT IDENTIFIER ::= { iso (1) identified-organizations(3) dod(6)

internet(1) security(5) mechanisms(5) pkix(7) on(8) 4 }

HardwareModuleName ::= SEQUENCE { hwType OBJECT IDENTIFIER, hwSerialNum OCTET STRING }

The hwType field is assigned from the manufacturer’s own OID arc according to its own policies. The OID MUST be unique for each different manufacturer’s device model and/or type. The manufacturer’s device type is NOT the same as the IEEE 2030.5 device type OID; instead it represents a single specific product from a specific manufacturer.

The hwSerialNum field is an unstructured field that the manufacturer should assign according to its own policies and SHOULD be related to the serial number or other identifier on the device’s external physical label.

The combination of hwType and hwSerialNum MUST be unique. For example:

vendor1Devices OBJECT IDENTIFIER ::= { vendor1 13 } meterNicV1 OBJECT IDENTIFIER ::= { vendor1Devices 1 1 }

HardwareModuleName = { OID:1.3.6.1.4.1.99999.13.1.1, -- Vendor1 MeterNic V1 OCTET STRING: 0x0a43218800 } -- Serial Number 44075-943936

6.11.8 Certificate profiles

6.11.8.1 Introduction

The certificates listed here have the normal (IETF RFC 5280) format and the descriptions for all the fields listed in the subsequent subclauses are described in IETF RFC 5280. The absence of a field in the certificate description is simply for conciseness and does not imply its absence in the certificate. In particular, the Issuer Name is omitted in most of the certificate descriptions as IETF RFC 5280 requires it to be identical to the Subject Name of the issuing certificate.

By specification, IETF RFC 5280 certificates are encoded using the ASN1 Distinguished Encoding Rules. For management or transmission purposes, they MAY be sent as ASN1 Distinguished Encoding Rules (a file or stream of octets) or BASE64 encoded and possibly armored (i.e., privacy-enhanced mail [PEM] format).

IEEE 2030.5 devices MUST accept unexpected (not listed in this profile) certificate extensions and MUST silently ignore non-critical unrecognized certificate extensions. Per IETF RFC 5280, devices MUST reject any certificate containing unrecognized critical certificate extensions.

6.11.8.2 Root certificate

A SERCA instance (e.g., contracted for CA operation) SHALL have exactly one self-signed certificate. There MAY be more than one SERCA instance.

The SERCA certificates are the root of trust for the Manufacturing PKI. They MUST contain the extensions described below and MUST have the name form as described. They SHOULD NOT contain any additional extensions.

 Issued by: Self-signed

 Issuer Name: O=Smart Energy, CN=IEEE 2030.5 Root, serialNumber=<n>

 Subject Name: O=Smart Energy, CN=IEEE 2030.5 Root, serialNumber=<n>

 Extensions

 certificatePolicy: Critical; 1:anyPolicy

 keyUsage: Critical; keyCertSign, crlSign

 basicConstraints: Critical; cA=true, pathLen absent (unlimited)

 subjectKeyIdentifer: see 6.11.6

NOTE—The root certificate is primarily a container for a Trust Anchor.12

6.11.8.3 Manufacturing hierarchy certificates

‌6.11.8.3.1 MCA certificate

MCA certificates MUST contain the extensions described below and MUST have at least the O and CN components of the Subject Name as described. They SHOULD comply with the name form as described below. They SHOULD NOT contain any additional extensions.

 Issued by: SERCA

 Subject Name: C=<country>, O=<Manufacturing Org>, CN=IEEE 2030.5 MCA, serialNumber=<num>

 Extensions:

 certificatePolicy: critical; at least one IEEE 2030.5 device type Identifier OID as a policyIdentifier

 keyUsage: critical; keyCertSign

 basicConstraints: critical; cA=true, pathLen=1

 subjectKeyIdentifier: see 6.11.6

 authorityKeyIdentifier: see 6.11.6

‌6.11.8.3.2 MICA certificate

MICA certificates MUST contain the extensions described below and MUST have at least the O and CN component of the Subject Name as described. They SHOULD comply with the name form as described below. They SHOULD NOT contain any additional extensions.

 Issued by: SERCA or MCA

 Subject Name: C=<country>, O=<Manufacturing Org>, CN=IEEE 2030.5 MICA, serialNumber=<num>

 Extensions:

 certificatePolicy: critical; at least one IEEE 2030.5 device type Identifier OID as a policyIdentifier

 keyUsage: critical; keyCertSign

 basicConstraints: critical; cA=true, pathLen=0

 subjectKeyIdentifier: see 6.11.6

 authorityKeyIdentifier: see 6.11.6

‌12 Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement this standard.

‌6.11.8.3.3 Device certificate

Device certificates MUST contain the extensions described below. The Subject Name field MUST be empty. They SHOULD NOT contain any additional extensions. Except as modified by 6.11.4, the certificate is compliant with IEEE Std 802.1AR.

The device type identifier OID(s) MUST be selected from those present in the issuing certificate’s certificatePolicy extension.

 Issued by: SERCA or MICA

 Subject Name: [EMPTY]

 Extensions:

 certificatePolicy: critical; generally exactly one IEEE 2030.5 device type identifier OID as a policyIdentifier

 subjectAlternativeName: critical; one GeneralName of type OtherName of hardwareModuleName (see 6.11.7.4 above for specific field values)

 keyUsage: critical; one or more of keyAgreement, digitalSignature

 authorityKeyIdentifier: see 6.11.6

‌6.11.8.3.4 Device test certificate

Device test certificates MUST contain the extensions described below. The Subject Name field MUST be empty. They SHOULD NOT contain any additional extensions. Except as modified by 6.11.4, the certificate is compliant with IEEE Std 802.1AR.

The device type identifier OID(s) MUST be selected from those present in the issuing certificate’s certificatePolicy extension.

NOTE—This is the same format as the device certificate with the exception of an additional id-IEEE 2030.5-po- device-auth-test as policyIdentifier in the certificatePolicy extension.

‌6.11.8.4 Other certificates

6.11.8.4.1 Introduction

There are a few other certificates that an IEEE 2030.5 device may see.

6.11.8.4.2 Additional certificates for IEEE 2030.5 native devices

6.11.8.4.2.1 General considerations

In addition to the certificates described in 6.11.8.3.3, native devices MAY include certificates (and their related key pairs) issued outside of the Manufacturing PKI. The provision of such certificates and support for them is OPTIONAL.

A manufacturer MAY contract with any reputable certificate authority for the issuance of non-IEEE 2030.5 Manufacturing certificates incorporating RSA public keys. The purpose for doing so is to provide

backwards-compatible support to client devices, software, and systems that may not yet support Elliptic Curve.

Non-IEEE 2030.5 certificates MAY be placed in the device at one of two times:

 During manufacture, either as a complete credential incorporating both private key and certificate, or as a certificate issued for a public key generated by the device.

 During customer install as an over-the-net installation, assuming connection to the Internet.

For the latter approach, the specific protocol used to install the certificate is vendor-dependent and should assume only normal Internet connectivity. Specifically, it should not depend on any “proxy” or third-party assistance within the customer’s home or the service provider’s back-office.

6.11.8.4.2.2 Certificate structure and certificate chain considerations

The certificate installation for these additional certificates MUST include the complete chain of certificates needed to validate the certificate, including the root of trust certificate for the chain.

The certificates MUST contain an RSA 2048-bit public key, and MUST be signed using SHA256withRSA. They SHOULD contain an expiration data not later than 31 December, 2028. As the provision of RSA certificates is considered a transition mechanism, this is an appropriate way to phase out the use of such certificates and the RSA signature algorithms. Intermediate certificates in the chain SHOULD contain an expiration date not earlier than 31 December 2020.

The IEEE 2030.5 device SHOULD permanently stop using the certificate and related private key upon certificate or chain expiration if the device has a mechanism for determining time and date.

The Subject Name form for the device certificate MAY be any form approved by the certificate issuer. This standard recommends that the Subject Name be crafted as: “C=<Country of certification>, O=<Manufacturer>, OU=<Device type>, UID=<Serial Number>.” An RSA certificate MUST NOT use a SubjectAlternativeName extension in place of a SubjectName unless it is identical to the SubjectAlternativeName extension in the device’s device certificate.

6.11.8.4.2.3 Use case

The above-described certificates are targeted for use when an external client connects to a server using TLS. The TLS negotiation and response is thus:

 When an IEEE 2030.5 device containing an additional RSA certificate receives a TLS Client Hello containing only a supported RSA cipher suite, it SHOULD answer any certificate negotiation with the non-IEEE 2030.5 RSA certificate.

 If an IEEE 2030.5 device receives a TLS Client Hello containing both EC and RSA supported cipher suites, it SHOULD respond using its EC device certificate, regardless of cipher suite preference order.

 If an IEEE 2030.5 device without an additional certificate receives a TLS Client Hello containing only an RSA cipher suites, it MUST reject the connection with the appropriate code.

6.11.8.4.3 Self-signed client certificate

Any application designed to talk to native IEEE 2030.5 products or applications implementing IEEE 2030.5 functions may create a credential for itself consisting of a self-signed (IETF RFC 5280) certificate.

The application generates the key pair and binds the public key in a certificate. The credential privilege is installed in the IEEE 2030.5 device by either passing the certificate or a fingerprint of the certificate along with the credential privileges to the appropriate IEEE 2030.5 application using an enrolment protocol (not specified here) or other mechanism (e.g., web portal mechanism for moving from unsecure to secure).

An IEEE 2030.5 device or application acting in a client role SHALL reject a self-signed certificate if presented by the server. An IEEE 2030.5 device or application acting in a server role MAY legitimately receive a self-signed certificate from a potential client. The server SHALL verify that the self-signed certificate follows the format described below and SHALL reject the certificate if there are any discrepancies. A server MUST NOT treat a self-signed certificate received through a TLS handshake as corresponding to a root CA, unless the public key carried in the self-signed certificate is the same as one of the pre-provisioned roots.

 Issued by: Self-signed

 Subject Name: Any—suggested: O=<application name>, CN=<12-digit random hex string>

 Issuer Name: Identical to Subject Name

 Validity: notBefore: time of issue; notAfter: maximum of time of issue plus three years

 Subject Public Key and Signature: SHOULD be EC P-256 and SHA256withECDSA, MAY be RSA 2048 and SHA256withRSA

 Extensions:

 keyUsage: critical; at least digitalSignature, others as appropriate

 certificatePolicy: critical; at least one policyIdentifier:id-IEEE 2030.5-po-selfsigned-client

‌6.11.8.4.4 Generic client certificates for non-IEEE 2030.5 entities

In addition to application issued self-signed certificates, an application may use a certificate issued by a global or local CA as an application credential for use with the IEEE 2030.5 protocol. As with a self-signed certificate, the credential privilege is installed in the IEEE 2030.5 device or application by either passing the certificate or a fingerprint of the certificate along with the credential privileges. At a later date, IEEE 2030.5 may specify further uses for certificates not issued under the IEEE 2030.5 certificate hierarchies.

There are no differences between the uses for a self-signed client certificate and “other” client certificates. The major difference is simply how the certificates are issued or who issues them. One example of an “other” client certificate would be an email or SSL client certificate issued by one of the well-known Certificate Authorities.

Client certificates by the IEEE 2030.5 definition are those that do not contain a basicConstraints extension.

‌6.11.8.4.5 Generic server certificates for non-IEEE 2030.5 entities

IEEE 2030.5 devices or applications may need to connect to TLS servers secured by server certificates issued by global or local CAs not affiliated with IEEE 2030.5. For interoperability with this profile, those certificates MUST meet the following requirements:

 MUST contain either an RSA 2048-bit public key or a EC P-256 public key

 MUST be signed either using either the SHA256withRSA or SHA256withECDSA algorithms

In addition, the IEEE 2030.5 client device MUST have a valid root of trust for the server certificate. This can be installed at manufacture, or installed by the operator or owner after the device is operational. The methods for the installation of these additional roots of trust are vendor specific.

The connectivity of IEEE 2030.5 devices to external devices is subject to further specification.

6.11.9 Device requirements

6.11.9.1 Private-key protection

Device manufacturers SHOULD ensure that, once installed, private keys cannot be exported from the device.

6.11.9.2 Trusted key store protection

Device manufacturers SHALL ensure that the current active Smart Energy Root CA (SERCA) certificates or root public keys are embedded in the device at the time of manufacture and firmware upgrade. They SHALL ensure that, once installed, the Root CA public keys cannot be overwritten via an over-the-air action, except as a by-product of a successful firmware upgrade.

6.11.9.3 Certificate usage

Device manufacturers SHALL ensure that a complete and valid Manufacturing PKI certificate chain (e.g., SERCA, MCA if any, issuing MICA if any, and device certificate) is embedded in the device at the time of manufacture.

In an authentication exchange, the device SHALL supply a complete and valid chain comprising its own certificate and any intermediate CA certificate between the device and the root (i.e.; all certificates in its chain except its SERCA).

6.11.9.4 Trusted certificate store

Vendors SHOULD incorporate an update of the trust store as part of any firmware update where appropriate. Vendors MAY provide a mechanism for a consumer/customer to set the trust status of any Root CA certificate and to add and delete such certificates from the trust store of their owned device.

6.11.10 Certificate verification

6.11.10.1 Introduction

IEEE 2030.5 devices and applications MUST follow the procedure defined in Section 6 of IETF RFC 5280, to verify certificates.

Certificate verifiers MUST reject certificates that contain one or more unsupported critical extensions. Policy-mapping is not supported, and certificates containing policy mappings MUST be rejected.

Policy-qualifiers are not supported. Therefore, issuers SHOULD NOT include policy qualifiers in certificates. However, verifiers SHOULD NOT reject certificates containing policy qualifiers unless there are other reasons to do so.

Name-constraints are not supported and certificates containing name-constraints MUST be rejected.

Any extension not listed by name within this document SHOULD NOT be included within a compliant certificate and, if included, MUST NOT be marked critical.

6.11.10.2 Additional considerations for serving IEEE 2030.5 to non-native entities

An IEEE 2030.5 device MAY implement OCSP for the sole purpose of validating non-IEEE 2030.5 certificates (e.g., as received from clients and applications using generic or self-signed client certificates, or when contacting generic servers). In addition or in lieu of this, an IEEE 2030.5 device or application may use a white list or other access control list to determine acceptance of an offered client certificate from an external source. An IEEE 2030.5 device or application MUST NOT use OCSP for the purpose of attempting to validate Manufacturing PKI-issued certificates.

As none of the Manufacturing PKI CAs issue either CRLs or run OCSP servers, no non-IEEE 2030.5 device or application may use CRLs or OCSP for the purpose of attempting to validate IEEE 2030.5 certificates.

6.11.11 Certificate-related labeling requirements

For the purposes of access control lists and other human-readable actions, the device will be identified by the data listed in 6.3. These data may be used as appropriate to label a device or its packaging.

< 上一个 | 内容 | 下一个 >