To conclude the trust management aspect of my dissertation and COSYLab, this blog presents digital certificates' content used in the certificate management system described in the previous blog [1]. Therefore, in the remainder of this blog, different building blocks of digital certificates are documented: (1) building identifiers, (2) common certificate structure, and (3) constraints for certificate validation.

Identifiers' structure

In general, identifiers must provide a system-wide, unique, recognizable name for an entity. This name can, but need not, have semantic value for other system entities and users. For example, domain names used in the DNS system - google.com, univie.ac.at, provide an easily understandable association with their platforms. In contrast, IP addresses like 216.58.223.9 or 172.217.30.9 provide barely any semantic for users.

Identifiers used in COSYLab tend to contain semantic information, describing the hierarchical position and the type of entity holding the identifier. The schema has been designed for that purpose, providing a dot-delimited structure for building identifiers. Left-to-right, identifier parts document:

1. platform in which the entity is registered, i.e., COSYLab
2. entity's type - Cloud or Fog Service, IoT device, or User
3. recognizable name for the entity (e.g., FTA for Fog Service, SmartLight for IoT device, or username for user)
4. optional fields like a unique identifier of the parent entity in the hierarchy (e.g., TNTA for FTA)
5. general identifier - randomly generated value ensuring identifier's uniqueness 

Certificate structure - common fields

Certificates managed in COSYLab are built using the standard X.509v3 certificates [2] applied in numerous PKI systems. Certificate content provided in the example for FTA entity contains several parts:

• Issuer information - identifiers of the CA that issued the given certificate - TNTA in this example
• Subject information - identifiers for the certificate holder - FTA in this example
• Validity period - per default limited to one year in COSYLab
• Certificate identifier - serial number
• Encryption-related information - signature algorithm (ECDSA), FTA's public key, and certificate's digital signature.

Certificates structure - constraints  

Beside the common certificates' field that are present for each COSYLab entity, additional capabilities used for certificate validation are described through X.509v3 extensions. These capabilities specify following certificate aspects: (1) for which purposes the certificate can be used - encryption procedures, certificate issuance, etc. and (2) certificate revocation endpoints and validation signatures. Example provided bellow documents the X.509v3 extensions present in the FTA's certificate.

FTA's extensions are limiting FTA to use its certificate to sign documents, messages, and other certificates (Key Usage extension), as well as to issue further certificates to other FTTTP components [3], thus to act as a CA (Basic Constraints extension). Furthermore, depending on the certificate type FTA has - issued by TNTA or self-signed [1], its certificate can be validated as described in the extensions: (i) CRL Distribution Points + Authority Key Identifier, which specify the endpoint for certificate revocation in the CTFTP and the identifier of the certificate that should be used to verify CRL's digital signature or (ii) Authority Information Access, which specifies the OCSP endpoint in the FTTTP.

Through this, the top-level insights on the keys and certificates exchange in COSYLab are described, which closes the trust management topics. In the following blogs the focus will be shifted to the deployment of COSYLab components in Fog, providing extensive insights on the feasibility of such a deployment approach.

[1] https://www.netidee.at/trustworthy-context-aware-access-control-iot-env…

[2] S. Chokhani, W. Ford, R. Sabett, C. Merrill, and S. Wu. Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. RFC 3647 (Informational). Nov. 2003. url: https://www.rfc-editor.org/rfc/rfc3647.txt.

[3] https://www.netidee.at/trustworthy-context-aware-access-control-iot-env…