Use of Name Redaction for Mass Devices
SECOM
Mitaka
Tokyo
Using wildcard certificates is
the simplest option, but it is not suitable for use with massive numbers of devices. Devices with a common wildcard certificate would need to share a private key, which would dramatically increase risk of key leakage.
Logging a name-constrained intermediate CA certificate in place of the
end-entity certificate,
and is suitable for mass devices, as it improves the scalability of the log server. However, it requires some non-scalable operations on the part of the CA
(i.e. issuing new intermediate certificate.).
Domain-label name redaction mechanism reduces the burden put on the CA.
In addition, it allows CAs to operate mass devices more flexibly.
Furthermore, geographic information is very useful for mass device management, and service providers may want or try to use
that information with certificates.
However, this information might be useful for attacker also.
By hiding this information for attacker, this mechanism prevents large-scale physical attacks on devices.
However, this option increases the implementation complexity considerably.
When an IoT service provider uses server certificates, the service provider will choose one of following.
In this section, we describe positive and negative points for each methods
(including methods, which does not use name redaction).
Pro: Do not need any change with current mechanisms.
Con: Service providers need to construct a new trust store. As the number of IoT services increases, it will become hard to manage the trust store, both for service providers and end users. ("scalability of trust store" issue)
While private roots could be used, it could prevent interoperability, and incompatibility with modern browser software could force IoT device software to rely on custom software that likely would not receive security updates (as browser software does) leading to the same kind of problem of "frozen" legacy root stores that can't be updated that we saw during SHA-1 deprecation problems.
Since a mississued certificate for an IoT device would affect security of the Web,
Service provider would have to maintain an OTA update mechanism for IoT devices to maintain security and crypt agility.
Some of the methods below may provide incentives for service providers to use such devices.
Do not use name redaction.
Log all end-entity certificates :
Pro: Compatible with current mechanism.
Con: log server needs to deal with enormous log ("scalability of log server" issue).
IoT devices (cameras, sensors, etc.), can be proxies for DOS attacks.
Unredacted CT logs may help an DOS attacker to construct a botnet for DOS attack.
Logging Reveals Commercially Sensitive Information also.
Manufacturers using IoT certificates possibly won't want to show the number of devices
they have shipped; redaction may help keep this information private.
Competitors scanning CT logs could infer new product/service offerings prior to their public release.
Disabling CT log checking with browser policy :
Pro: Compatible with current CT Log server.
Con: Browser needs to implement mechanism, and list of intermediate CAs not to check.
Use name redaction
With wild card Certificate :
Pro : Near-compatible with current CT mechanism.
Con : Secret keys could be leaked from IoT devices.
With name-constrained intermediate CA :
Pro: Near-compatible with current log server's implementation.
Con: Browser needs to support name-constrained intermediate.
CA need to implement name-constrained intermediate.
domain-label name redaction :
If "attacker can construct *list* of devices very *efficiently*", that list can assist attacker (typically, construction of botnet).
This mechanism limits the efficiency of construction, instead of preventing the construction of a list.
TODO: describe how CA can get assurance for domain owner's control over underling domain.
It should contain some management mechanism, and need further discuss.
Portions of this text were unabashedly borrowed from I-D.draft-strad-trans-redaction-01.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
The Base16, Base32, and Base64 Data Encodings
This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]
Certificate Transparency
This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.
Certificate Transparency Version 2.0
This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.
Certificate Transparency: Domain Label Redaction
This document defines mechanisms to allow DNS domain name labels that are
considered to be private to not appear in public Certificate Transparency (CT)
logs, while still retaining most of the security benefits accrued from using
Certificate Transparency.
Baseline Requirements for theIssuance and Management of Publicly-Trusted Certificates
CA/Browser Forum