4
edits
(→IoT Usage: "IoT usage" is not to support current IoT devices, but to have better ecosystem in the future.) |
(→Alternatives to Redaction: add comment for some of alternatives) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 35: | Line 35: | ||
=== Makes DOS Easier === | === Makes DOS Easier === | ||
IoT devices (cameras, sensors, some car uses, etc.), can be proxies for DOS attacks. Unredacted CT logs may help the DOS attacker to contract botnet for DOS attack. | |||
===== Response ===== | ===== Response ===== | ||
Line 53: | Line 52: | ||
* Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private. | * Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private. | ||
* Competitors scanning CT logs could infer new product/service offerings prior to their public release. | * Competitors scanning CT logs could infer new product/service offerings prior to their public release. | ||
domain label name redaction do not work fine with above problem, but some other redaction mechanisms (i.e. use of name-constrainted intermediate, single entry for STAR certificate) should work. | |||
===== Response ===== | ===== Response ===== | ||
Line 126: | Line 127: | ||
* Disabling CT via browser policy in enterprises | * Disabling CT via browser policy in enterprises | ||
* Private roots | * Private roots | ||
**As the number of IoT devices increases, number of private roots would increase as well. Managing many private roots is expected to put a burden on users | |||
* Wildcard certs | * Wildcard certs | ||
* Log a name-constrained intermediate | * Log a name-constrained intermediate | ||
**As a one of "redaction mechanism", this mechanism was removed from RFC6962-bis with “domain label name-redaction”. Currently, there is not any specification for this mechanism. | |||
* CT-logging anyway | * CT-logging anyway |
edits