BlackBerry's QNX group which has presence in automotive telematics
implementations.
    Certicom supported a private consortium to manage a V2V SCMS,
indicating that this approach could help ``accelerate the deployments
of V2X systems'' serving both infrastructure and aftermarket devices.
They stated that a possible ``concern could arise if regulation
unnecessarily limits the opportunity for participants to drive
commercial innovation.'' Certicom expressed interest in the SCMS
operational roles of the Certificate Management Entity (CME) such as
operating a Certification Authority (CA) and/or a Registration
Authority (RA). However, Certicom indicated revenue models and costs
would need to be better understood before committing definitively to
any portion of the system operation.
    Certicom commented that long-term viability of the SCMS is highly
dependent on public acceptance. As such, participants in the system
need a strong public identification (brand) and experience with
successful security, safe, reliable and privacy implementations.
    During the agency's meeting with Certicom, the discussion focused
on clarifying the RFI responses but also in key areas of revenue
generation, security approaches, and certificate and device management
approaches used for Blackberry devices and other implementations that
Certicom has supported, which includes public utility installed
residential ``smart meters.''
    Certicom indicated there could be many reasons that entities would
want to participate in a National SCMS and there could be potential
opportunities presented such as the support of the security needs for
manufacturing and system operations. In addition, expanded future
roadside equipment could lead to yet-unknown revenue generation
opportunities. Overall, V2V and a supporting SCMS could, in theory,
``create a whole new market.'' Certicom also suggested participants in
the SCMS could generate on-going revenue by royalties from device
manufacturers.
    In terms of approaches to device security, Certicom indicated there
are at least three security key-scenarios for devices. The following
table provides an overview of these approaches and a corresponding,
relative level of security provided by each.

                                   Table V-2--Overview of Security Approaches
----------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------
Security Method......................  PKI....................  Keys/Certificates sent   In device chipset
                                                                 to device at time of     (``silicon'').
                                                                 manufacture.
Example..............................  Thermostat.............  Telematics.............  Blackberry.
Relative Security....................  Sufficient.............  Better.................  Best.
----------------------------------------------------------------------------------------------------------------

    When discussing device and certificate management, Certicom
provided an overview of three certificate distribution and management
systems: Blackberry PKI, the ZigBee Smart Energy public utility
residential meter system, and Certicom's approach to certificate and
asset management for device original equipment manufacturers (OEMs).
    The certificate service for Blackberry devices is designed for
scalability, and secures devices from ``birth'' where a registration
``seed'' is embedded in the a device's onboard microchip (``silicon'')
at the time of device manufacturer. The registration seed could be
viewed like a V2V enrollment certificate, all of which is linked to the
``root of trust'' for the Blackberry ecosystem.
    Certicom's overview of the ZigBee public utility smart meter
certificate system varies from Blackberry devices,

in that devices participating in that system are supplied from various
manufacturers--similar to how V2V device implementation is envisioned,
but the ecosystem itself could be viewed as localized.
    In this implementation, ZigBee ``Smart Energy'' device certificates
utilize an EQCV format issued in batches of one million. Certicom
indicated they are able to issue approximately one million certificates
in approximately one and half hours of processing. Each device
participating in the system is identified by unique vendor
identification, and verification is performed to confirm that each
device's media access control (MAC) \222\ address is unique. Key pairs
for each device are then bound to the device MAC address and vendor ID
through the certificate. Figure V-2 shows a graphic representation of
the ZigBee certificate management system.
---------------------------------------------------------------------------

    \222\ Media Access Control address refers to the unique 48-bit
serial number in the network circuitry of Ethernet and Wi-Fi devices
that identifies that machine from every other globally. See http://www.pcmag.com/encyclopedia/term/46422/mac-address (last accessed
Jul. 14, 2015).
[GRAPHIC] [TIFF OMITTED] TP12JA17.011

    Finally, Certicom provided an overview of a certificate authority
and asset management system that they are able to supply for device
original equipment manufacturers. The system is designed to enable OEMs
and silicon vendors to remotely secure devices that are assembled at
geographically-dispersed locations, similar to how vehicles are
assembled. The system described provides operational visibility and
control of secure key injection into a device at time of manufacture or
initialization, secure device serialization and tracking, and support
for anti-cloning and anti-counterfeiting. Figure V-3 provides a
representation of this system and shows the remote management across
various locations. The ``tester'' would be the point of security key
injection into a device.

[GRAPHIC] [TIFF OMITTED] TP12JA17.012

    Certicom indicated that this system enables OEMs to manage and
distribute the sensitive security keying material, along with
potentially other sensitive information, to an untrusted contract
manufacturing environment supplying components for their end product.
Figure V-4 shows the process flow for loading security information to a
device in an untrusted manufacturing environment.
[GRAPHIC] [TIFF OMITTED] TP12JA17.013

    As mentioned elsewhere in this section, device management also
involves potential updates to device software to support technology
updates and, importantly, in support of potential device recall
scenarios. Certicom discussed Blackberry's OTA update service used for
updating, configuring, and managing software and applications. Their
updates leverage the existing Blackberry exclusive secure
infrastructure for global distribution. This system also gathers status
and data to support fleet monitoring capabilities for device operation.
A graphic overview of the system is shown in Figure V-5.
[GRAPHIC] [TIFF OMITTED] TP12JA17.014

    With end-of-life and misbehavior being key elements of a national
V2V deployment, the agency inquired about approaches for managing
devices under these conditions. Certicom indicated that Blackberry
devices can be remotely made non-functional (``bricked'') when a device
is determined to be out of service, stolen, not functioning properly or
potentially ``misbehaving.'' Reactivation of a ``bricked'' device
requires interaction with Blackberry.
(7) SiriusXM Satellite Radio
    SiriusXM Satellite Radio provided a response to the SCMS RFI and
also met with the V2V NPRM team as follow-up. Their written response to
the RFI focused on the opportunity for satellite transmission to
perform non-safety-critical, ``back haul'' type operations for a SCMS.
This could include certificate distribution, over the air updates, and
certificate revocation list distribution, among other potential
supporting transactions. SiriusXM commented that employing a satellite
network as an alternative distribution path for safety certificates and
the CRL would promote the development of a V2V system by enhancing
scalability and the SCMS network footprint, and enable faster
distribution of security information for V2V-equipped vehicles.
    SiriusXM indicated that satellite transmission could potentially
``bridge the gap'' between initial V2V deployment and roadside unit
deployment and, in the longer term, support more remote regions that
may not have roadside units deployed. SiriusXM indicated that their
infrastructure ``could provide the ubiquitous, simultaneous, and robust
distribution of security certificates and the certificate revocation
list (``CRL'') in a V2V system.'' SiriusXM's satellite network covers
the contiguous United States and portions or Canada and Mexico, which
could possibly assist with potential cross-border challenges. Their
network also includes signal repeating equipment to supplement service
in urban areas where satellite reception could be blocked by buildings
or other obstacles.
    According to SiriusXM, 69 million vehicles are currently equipped
with their radios, and they expect this to increase to 100 million
vehicles by 2017 as approximately 70% of new vehicles are equipped with
their receiver.
    When discussing privacy, SiriusXM indicated that no subscription
would be required to receive satellite V2X data and that it would be
available to any vehicle equipped with their satellite receiver.
SiriusXM did not present any potential revenue generation concepts
during the discussion. Additionally, SiriusXM stated V2X will be a
transparent data service on its system, meaning that no V2X-related
data is collected on the vehicle, and that the satellite delivery
system has no knowledge of which vehicles are active and receiving data
or where vehicles are located.
    In terms of device management, SiriusXM suggested a hardware
security module (HSM) for V2V-enabled devices as part of a trusted,
secure data exchange environment. SiriusXM provided very detailed
technical descriptions of how device-level security could be
implemented and managed using satellite radio service. This included
discussing the potential use of group codes, interaction with the HSM,
in-use certificate downloads, available service channels, and revoked
vehicle identification, all of which leverages its experience with the
development and deployment of its satellite radio network that appears
to have addressed many similar challenges found in V2V device
deployment and management.
(8) Ford Motor Company and Volkswagen Group of America
    Ford Motor Company (``Ford'') and Volkswagen Group of America
(``Volkswagen'') submitted joint comments to the SCMS RFI. Together,
Ford and Volkswagen indicated they are encouraged by the progress made
in the collaborative activities between NHTSA and CAMP, in which they
participate. However, they state in their comments that remaining items
need resolution to enable an effective deployment of a V2V
communications system, such as: (1) NHTSA's authority to mandate an
SCMS; (2) an acceptable and stable funding model, and; (3) measures to
address potential liabilities associated with participating in and/or
being subject to a SCMS.

    Ford and Volkswagen commented that the SCMS cannot be a private
entity because vital functions of the SCMS cannot be delegated to a
``private'' entity, ``which lacks the authority to require all
participants in a V2V (let alone V2X) communication system to adhere to
the system's necessarily rigorous operational policies, and enforce
revocation based on unacceptable performance.'' Ford and Volkswagen
stated that they, other OEMs, and others that will necessarily rely on
the SCMS must have a role, along with government, in establishing SCMS
operational policy. Additionally, they stated that Federal authority
over the SCMS is essential and a binding governance board for SCMS
management is needed.
    Finally, Ford and Volkswagen stated that funding for centralized
SCMS components or functions should come from a federal source. They do
not support any funding model relying on the sale of data to third
parties, and, additionally, the SCMS funding model ``should not be
based on a potential requirement that specific services must be enabled
within the vehicle to offset operational costs.'' Conversely, non-
centralized components, like the certificate management entity (CME) or
registration authority (RA), could be established independently for
their own use.
(9) SAE International
    The Society of Automotive Engineers (``SAE'') responded to the RFI
with interest in playing a supporting role in SCMS deployment. SAE
indicated interest in working with SCMS stakeholders in a partnership
and/or larger consortium to support the SCMS functions, ``through a
combination of standards development, conformance programs and
training.''
    SAE International standards J2735 and J2945 were revised and are
being developed to support a national V2V deployment by providing a
consistent, standardized approach to V2V device implementation across
the industry.
(10) The American Motorcyclist Association
    The American Motorcyclist Association (``AMA'') commented to the
SCMS RFI by urging DOT to test the V2Vcommunication systems to ensure
that motorcyclists' safety and privacy are secure. AMA expressed their
support for DOT's position ``for further testing before adopting the
rule authorizing U-NII devices (e.g., Wi-Fi) to operate in the band to
ensure vehicles using advanced crash-avoidance and vehicle-to-vehicle
technologies are not compromised.'' AMA also expressed concern about
the potential for ``hacking'' into a future V2V network, and
specifically, the potential to manipulate traffic signals which could
be ``especially disconcerting for motorcyclists who comprise the most
vulnerable roadway user group.'' AMA closed their comments stating that
the safety of all highway users should always be a priority whenever
new technologies are considered.
(11) Alliance of Automobile Manufacturers, Inc.
    The Alliance of Automobile Manufacturers, Inc. (``Alliance'')
reiterated their comments to NHTSA's V2V ANPRM where they ``agreed with
NHTSA's assessment that a strong SCMS is necessary for a properly
functioning V2V communications system.'' The Alliance also reiterated
its ANPRM comments expressing concerns with how a privately-run SCMS
could address the broad structural and governance challenges that an
SCMS manager would need to address, such as:

 Funding, deployment, operation and maintenance of a DSRC-based
V2X security communications network
 Sustainable funding for V2X PKI security system operations and
management
 Governance of a V2X security system (Rules of Use,
Certification, and system access)
 Protection of consumer privacy
 Liability, risk management, and intellectual property
protections
 International considerations including possible Canada-US-
Mexico cross-border traffic, international agreements, or standards
harmonization.

    The Alliance maintained in its RFI response that addressing the
above policy issues, which are necessarily national in scope, requires
strong unified Federal leadership, not just presence.
(12) Association of Global Automakers
    The Association of Global Automakers (``Global Automakers'')
provided general comments along with direct responses to the RFI
questions. In its comments, Global Automakers strongly supported a
public-private partnership model for SCMS operation by stating that
``the agency has underestimated the necessary governmental role in
managing the SCMS and too narrowly constrained the participation of
other agencies in SCMS operations. Contractor operation of many aspects
of the SCMS is feasible but must be conducted under the authority and
supervision of a significant governmental entity.''
    Global Automakers further stated that, to be effective, the SCMS
must be a monopoly, which is not allowed under law for a private
entity, and that funding for the SCMS should come from the government
rather than from revenue generated by consumers; less potential
consumer subscription funding opportunities for some potential V2I
services. Additionally, the SCMS should be developed to support V2V and
V2X holistically, at the outset, in partnership with the Federal
Highway Administration (FHWA) and possibly other agencies such as the
Federal Communications Commission and the Federal Trade Commission
where privacy is of concern. Global Automakers stated that cross-agency
coordination and harmonization is critical to the effective operation
of the SCMS.
    Global Automakers expressed concern with the potential approach for
the ``Device Non-compliance and Potential Recalls'' discussion in the
RFI materials, specifically, that it believed that the approach
suggested by the agency would undermine consumer privacy, be
impractical, and be redundant to systems that are already in place to
manage recalls. It commented that the proposed ``link between specific
installed V2V devices or production lots of devices and enrollment
certificates'' would create a potential perception that V2V
communications could be traced to individual vehicles and drivers.
(13) Verizon Communications, Inc.
    Verizon Communications' RFI response focused on potential steps and
pathways to achieving a National SCMS deployment and focused on three
key approaches to SCMS policies and operations standards and potential
adjustments to the PKI implementation. In more detail, Verizon
suggested that: (1) NHTSA should define a system of policies,
regulations, workflows, and technical interoperability that provides
for the management and control of the overall SCMS; (2) implement an
``identity PKI'' as a baseline and ``bootstraps'' anonymously allowing
linkage between certificates and supporting potential device recalls;
and (3) an ``anonymity PKI'' solution that allows the device to perform
any necessary operations anonymously.
(14) General Motors, LLC
    General Motors, LLC (``GM'') submitted comments to the SCMS RFI
that also included broader V2V rulemaking comments. GM stated, in the

broader context of V2V, that they support NHTSA's rulemaking initiative
for all passenger cars and light trucks to be sold in the United
States, and that ``a comprehensive and connected ecosystem must be
developed and implemented offering seamless and trusted communication
between vehicles'' to obtain all the potential benefits of V2V
technology. GM commented that it strongly believes that a NHTSA
rulemaking process is the only method to successfully establish a V2V
ecosystem; that, as envisioned, the system cannot be established and
managed by a single manufacturer or industry group.
    Focused comments regarding the SCMS stated its belief in the
requirement for Federal oversight of the SCMS Manager, the central root
authority organization, direct engagement with the Misbehavior
Authority and coordination of certification labs.
(15) CTIA--The Wireless Association
    CTIA is an international nonprofit organization representing the
wireless communications industry. CTIA's members include wireless
carriers and their suppliers, as well as providers and manufacturers of
wireless data services and products. CTIA's comments to the SCMS RFI
focused on the benefit of leveraging existing authentication and
security technology, along with utilizing existing networks and
infrastructure to promote standardization and interoperability. CTIA
also stated that the private sector is best positioned to address V2V
SCMS cybersecurity and privacy concerns and should be utilized to help
implement cybersecurity best practices.
(16) Tesla Motors, Inc.
    Tesla Motors, Inc. (``Tesla'') commented primarily on the security
of the SCMS design presented in the V2V Readiness Report by urging
NHTSA ``to ensure that all possible security aspects are considered and
accounted for when implementing its chosen design.'' Tesla commented
that much more analysis and consideration needs to be given to the SCMS
before it is implemented as proposed. Tesla acknowledges that it has
not been involved with the Crash Avoidance Metrics Partnership (CAMP)
consortium and that this brings a new perspective to the CAMP SCMS
design.
    Tesla believes that, as envisioned, the CAMP system fails to
consider adequately how the system could be attacked or the vast
amounts of information that will necessarily pass between vehicles and
that NHTSA's proposed system has gaps that must be addressed before it
is implemented.
    Tesla narrowed its primary concerns into the following: (1) Because
inputs are insecure, false messages are likely, even with secure V2V
subsystems; (2) vehicles must have some way to determine whether
messages, particularly misbehavior reports, are legitimate; (3)
certificate revocation lists (``CRLs'') do not scale well for
widespread use; (4) public[hyphen]key cryptography is poorly suited to
the demands of an embedded, high[hyphen]speed environment; and (5)
transmitted messages could be the source of privacy breaches.
    Tesla concluded their comments by stating that ``the Company
believes that the CAMP system has fundamental issues and challenges
that must be revisited in order to allow for successful implementation
of the SCMS.''
(17) Intercede Ltd.
    Intercede, Ltd. is a software company solely focused on producing
and delivering identity and credential management solutions to entities
such as Government, Aerospace and Defense, Finance, Healthcare, Large
Corporations and Managed Service Providers. Intercede's response to the
RFI focused on the need for the SCMS to provide a secure and trusted
environment for V2X, and stated that it will be necessary to consider
the V2X communication devices over their entire lifetime, which was
defined as:
     Initial manufacture;
     Upgrade;
     Maintenance;
     Transfer of ownership;
     Renewal;
     Compromise;
     Natural end of life.
    Intercede's response went on to state that ``it is also important
to consider the interactions beyond the communication channels that
must be established into a secure trust system. Failure to do so would
open up potential back doors into this trust system that could allow
for compromise to occur from within.'' Follow-up discussion with
Intercede stressed its views regarding the need for a complete, systems
approach to security--encompassing ``cradle to grave'' for devices. And
that, ``By adopting a controlled and secure approach to device identity
management, NHTSA will enable a strong trust environment to be
established that can then be built on for large-scale key generation
during the lifetime of the device in the field for V2X
communications.''
(b) SCMS RFI Agency Response
    The RFI responses and subsequent meetings benefitted NHTSA greatly
by providing additional technical perspectives on the SCMS PKI design.
For example, DOT had originally dismissed the use of satellites as a
viable communications media for transmission of security materials
between the SCMS and OBE, but our meeting with Sirius XM Radio brought
to NHTSA's attention the fact that, due to advances in technology and
the close working relationship between the auto and satellite
industries, satellite could in fact be a technologically and
economically viable, secure and private media for such security
transmissions. Similarly, the PKI technical model put forth by NHTSA in
its Readiness Report assumes that a single root must form the basis for
trust system-wide. However, as a result of meetings with CSS, NHTSA now
is aware of the possibility that, through use of a trust bridge, one or
more SCMS organizations, possibly representing different regions or
even manufacturers, may be able to co-exist and together, provide more
redundancy in security for V2V and V2X DSRC communications.
5. SCMS ANPRM Comments and Agency Response
(a) ANPRM SCMS Comments
    With limited exception, comments received in response to the ANPRM
generally endorsed the PKI design as an appropriate security solution
for V2V and V2I DSRC communications. For example, GM, the Alliance,
Toyota, and the Automotive Safety Council all concurred that the SCMS
design described in the ANPRM and the V2V Readiness Report should
provide the required level of security while also protecting the
privacy of the end users. Throughout all the comments there were two
major concerns with the SCMS design that were cited by multiple
commenters: (1) The overall complexity of the design; and (2) a
fallback plan for a compromised root.
    One of the recurring comments in the ANPRM focused on the overall
complexity of the design of the SCMS and the plan for implementing such
a system. The design of the SCMS is more complicated than any existing
PKI systems due primarily to the need to protect the privacy of the end
users both from outsider and insider attacks. As such the various
functions in the system are separated logically and organizationally in
an attempt to ensure that one organization does not have access to all
the information needed to identify the end users. Therefore, this

level of complexity is necessitated by the system requirements.
    The second technical concern highlighted in the comments is the
impact on the system if the private key of the SCMS root certificate
authority is compromised. If the root CA is compromised, then this
would compromise certificates for all V2V devices, roadside
infrastructure devices, and SCMS components. Reissuing the certificates
for over 350 million end users would require a significant amount of
time and resources to complete. For example, all V2V devices would need
to be re-initialized in order to receive a new enrollment certificate;
however, this process must occur over a secure communications channel.
This may require all devices to return to the dealership or service
center in order to have access to the secure communications channel
required for the initialization process.
(b) ANPRM Agency Response
    In response to the first concern, the agency agrees that the level
of complexity of the design does increase the risk associated with the
implementation and deployment of this system. To combat that risk, one
commenter suggested that the system be implemented through a phased
development approach where components of the system are developed,
tested, and deployed incrementally. This approach would ensure that the
deployed components are secure and reliable for additional components
are deployed into the system. The agency agrees with this
recommendation and is employing in it the development of the SCMS
Proof-of-Concept. This system is being developed using an incremental
approach that focuses on first implementing and testing the core
components of the system, followed by the non-core components. After
the system is developed and tested, it will be operated for a
significant period of time by DOT. During this operational period,
existing V2V and V2I test beds will be integrated with the SCMS POC,
and it will provide the necessary security credential materials to
these test beds. The knowledge gained from the operation of the SCMS
POC will inform the development of the National SCMS that will be
required to support an eventual FMVSS.
    The agency also concurs that it would be a catastrophic event for
the root CA to be compromised, and as such we are exploring various
approaches for disaster recovery that can be implemented to mitigate
this risk. The SCMS Proof-of-Concept will implement and test root
management and disaster recovery solutions that will allow a root CA to
be revoked without requiring the recall and re-initialization of all
the V2V and V2I devices in a secure environment. One of the solutions
to be tested in the SCMS POC is a distributed root management approach
that utilizes root electors to manage the trust relationships in the
system. Another solution being evaluated includes the use of redundant
root CAs where only a single root is active at any one time. These
approaches will be tested and evaluated during the operation of the
SCMS POC to ensure that in the event of a compromised root, the system
can be recovered without the need to recall every V2V and V2I device.
6. SCMS Industry Governance
(a) The SCMS ``Industry''
    Deployment of an SCMS PKI to secure V2V DSRC communications will
require governance of a wide range of complex functions and involve
numerous public and private stakeholders, which together we refer to
here as the SCMS ``industry'' or SCMS ``ecosystem.'' We expect that
SCMS stakeholders will include: Manufacturers of OBE, RSU, and
aftermarket safety devices (ASD); certification labs that test OBE (and
potentially ASDs); organizations supporting V2V communications; auto
manufacturers; standards organizations; PKI experts; State and local
government users, and others. In Figure V-6, below, the shapes
represent different groups of organizations that interact with the SCMS
in some way. Some of these organizations will need to be stood up,
while others currently exist today and will likely expand their
operations to play a role in the SCMS. The overlapping of shapes
represents mutual reliance in executing operations, and the arrows
represent communication and the need for inter-organizational
arrangements. The SCMS is the focal point of the certificate management
industry, as it encompasses the CMEs that oversee all PKI functions
responsible for establishing the foundation of security in the V2V/V2I/
V2X system.

[GRAPHIC] [TIFF OMITTED] TP12JA17.015

    Some of the questions that NHTSA raised in the V2V Readiness Report
about industry governance structure for the SCMS include:
     How and by whom are decisions made about various policies,
standards, requirements, and practices?
     Who has the authority to mandate and enforce compliance
with the policies, standards, and industry requirements?
     Who makes up the overseeing financial, legal, management,
and executive operations of the entities in the SCMS?
     Is there a central industry body and, if so, who oversees
it? Who is part of this central industry body?
     How do the various entities interact with each other?
     How is risk and liability allocated across the
organizations?
     Who will own the intellectual property (data and software)
of the system and how will it be licensed (allocated) among responsible
entities?
    In answering these questions, NHTSA continues to explore a variety
of governance models (ranging from public to public-private to private)
as potential options for governing the SCMS industry. Due primarily to
the absence of Federal funds to support a public SCMS, to date NHTSA
has focused primarily on fleshing out a model of private SCMS ownership
and governance that assumes costs will be covered by increases in the
purchase price of new vehicles and V2V safety devices. As we noted our
V2V Readiness Report, in a private SCMS industry the organizational
structure and operation of the SCMS would be determined largely by
private owners and operators of CME components, under oversight of an
SCMS Manager (ideally an industry-wide coalition of CME owners and
other stakeholder representatives who, together, agree on the terms of
self-governance and system-wide rules and policies). The SCMS Manager
would provide critical system management by enforcing and auditing
compliance with uniform technical and policy standards and guidance
system-wide. Uniform standards and guidance would establish and ensure
consistency, effectiveness, interoperability, sustainability, and
appropriate privacy protections across the CMEs to facilitate necessary
communications, sharing of information, and operational connections,
and would be based in large part on existing technical and policy
standards applicable to PKI systems.
    The Readiness Report explained NHTSA's view that, in the context of
a privately owned SCMS ``industry,'' a private model could be a viable
mechanism for SCMS governance in which NHTSA would have only a minimal
role in ensuring system integrity, largely through its traditional
regulatory activities. We also indicated that NHTSA's existing legal
authority would accommodate the use of grants, cooperative agreements,
or other agreements to facilitate stakeholder--and even DOT--input into
governance of a private SCMS.
(b) ANPRM Governance Comments
    Comments to the ANPRM and Readiness Report relating to SCMS
ownership and governance came mostly from members of the automotive
industry and their trade groups. While agreeing with NHTSA's assertion
that a V2V system is not complete without a robust SCMS, almost without
exception, industry commenters vehemently disagreed that a private
self-governing industry coalition could be a viable mechanism for SCMS
system governance. Commenters believed that a private SCMS could not
provide the security, privacy, certainty, stability, long-term
functionality, or management of costs and risk required for a
nationwide SCMS to support V2V DSRC communications, and lacked the
legal authority to address cross-border issues

or require industry-wide participation and compliance with uniform
requirements. For these reasons, virtually all industry commenters took
the position that a strong leadership role for the Federal government
in the SCMS would be required for successful deployment of V2V and V2X
DSRC communications.
    For example, both the Alliance and Mercedes described the SCMS as a
``core government responsibility.'' Noting that ``for V2V to work
effectively, every vehicle manufacturer will have to participate in the
SCMS and abide by its rules,'' the Alliance explained that:

a private organization, such as a voluntary coalition of
manufacturers, cannot compel unwilling manufacturers to join the
organization, and cannot enforce deviations from the organization's
rules except by expelling misbehaving members. There is no effective
mechanism to ensure the universal participation of all manufacturers
and to compel their obedience to the necessary common SCMS
requirements. . .

    The Alliance also stated that ``resolution of policy issues
requires coordination among multiple federal agencies (FHWA, FTC, FCC,
EPA),'' and that ``Congress was best positioned to provide the needed
coordination and nationwide-scope for addressing infrastructure,
governance of networks and SCMS, consumer privacy, sustainable funding,
international cross-border and liability/IP policy issues.''
    Global commented that ``private sector options for operating the
Security Credential Management System (SCMS) do not guarantee certainty
over the management or the cost of operation the system and its long-
term stability.'' GM, likening the issuance of security certificates to
the minting of coinage by the Federal government, argued that ensuring
a secure V2V system would require that the Federal government: (i)
Operate or support operation of a central root CA that all V2V
certificates must use, or mandate that all V2V certificates use a
central root CA; and (ii) review and approve minimum levels of security
for the keys and cryptography used by the root CA and subordinate CAs
authorized by the root CA. Mercedes described the SCMS as a ``backbone
infrastructure, which must be set up and controlled with the leadership
of state and federal authorities'' and echoed the comments of the
Alliance that only Federal government oversight would ensure industry-
wide participation in an SCMS and compliance with its requirements.
Similarly, Honda commented that the federal government should be
responsible to ensure the safe and efficient operation of the V2V
security framework, and should consider a public-private partnership as
an option for the operation and management of the SCMS, with federal
oversight, supervision and funding.
    The agency agrees with commenters that, for a variety of policy
reasons, ideally the Federal government should play a more central
leadership role in the establishment and governance of a V2V SCMS. For
this reason, as detailed above, DOT now has taken the lead in working
with SCMS stakeholders to develop the policies and standards that
should form the basis for governance of a National V2V SCMS, as well as
to model and prototype organizational options for a governance entity
to manage SCMS operations.
(c) A Comparative Industry Example: ICANN
    In analyzing SCMS governance options, NHTSA and its research
partners have investigated a variety of industries with characteristics
similar to those seen as critical for a V2V SCMS governance model,
including security, privacy protection, stability, sustainability,
multi-stakeholder representation and technical complexity.\223\ We
investigated an array of public, public-private and private governance
models, with particular emphasis on safety-critical and privacy-
sensitive systems. We also examined how risk was managed in the context
these models. Some of the industries researched included:

    \223\ VIIC Assessment of Key Governance Policy Considerations
for a Connected Vehicle Cooperative Safety Communications System,''
dated March 12, 2013, at page 11 http://www.regulations.gov/#!documentDetail;D=NHTSA-2014-0022-0046 (last accessed Dec. 8,
2016).
---------------------------------------------------------------------------

 Internet Corporation for Assigned Names and Numbers (ICANN)
 DTE Energy Company
 Aeronautical Radio Incorporated (ARINC)
 End of Life Vehicle Solutions Corporation (ELVS)
 The FAA's Next Gen Air Transportation System
 The FRA's Positive Train Control
 Smart Grid
 The Rail/Transit Train Control Systems (ATC and CBTC)
 FMCSA's EOBR
 Coast Guard's MSSIS
 Army Corp of Engineer's MRGO
 Medical Devices failure and liability
 Security in nuclear industry and liability
 Warning/Signal Failures
 UAVs
 HIPAA/Health Care industry/Electronic Health Records (EHRs)/
CONNECT system
 Credit Card Payment industry and PCI standards
 Hospital/Health care industry

    Of the governance models we examined, governance of the internet
naming protocol systems (DNS) by the Internet Assigned Numbers
Authority (ICANN) possessed numerous characteristics that seem to
translate most directly to a private or public-private governance model
for the V2V SCMS. ICANN is a private, not-for-profit corporation
created by private sector entities in direct response to efforts by the
Federal government to privatize certain Internet-related tasks in a
manner that permits robust competition and international participation
in its management. ICANN is managed by a multi-stakeholder Board of
Directors (representative of the functional and geographic diversity of
the Internet) that oversees a number of Internet-related functions
previously performed directly on behalf of the Federal government by
other organizations, notably the Internet Assigned Numbers Authority
(IANA) (formerly located within the Department of Commerce but now
operated by ICANN). Pursuant to various Memoranda of Understanding with
ICANN (ICANN MOUs), the Department of Commerce agreed gradually to
transfer to ICANN certain Internet-related functions, with the goal of
having ICANN carry out operational responsibility for these functions
in a financially self-sustaining manner after a limited transition
period. At the same time, the Department of Commerce also entered into
a series of funded project agreements with ICANN, on a sole source
basis, to perform technical and policy activities required to
facilitate the transition of authority for those functions to
ICANN.\224\
---------------------------------------------------------------------------

    \224\ ICANN background information, contract and agreement
content can be found at http://www.ntia.doc.gov/page/docicann-agreements (last accessed Dec. 8, 2016).
---------------------------------------------------------------------------

    The ICANN MOUs and project agreements called for the Federal
government to exercise significant oversight of ICANN's activities
until such time as ICANN was stable and could provide certain
stability, sustainability and policy assurances to the Federal
government. After 11 years, the Department of Commerce gave up its
oversight of ICANN with respect to the operation and governance of
specific Internet naming protocol functions, but committed to ongoing
participation in ICANN's Governmental Advisory Committee (GAC). ICANN
continues to perform certain technical maintenance tasks under contract
to Commerce, as do other Commerce contractors. In 2014,

Commerce announced its intention to work with ICANN to privatize key
Internet domain name functions still remaining under its control.
    How is ICANN relevant to governance of the V2V SCMS? ICANN provides
NHTSA with a potential road map for how it can work with public and
private stakeholders to develop a successful governance structure for a
multi-stakeholder, geographically and functionally diverse technology-
intense system not unlike V2V. Like the V2V SCMS, successful deployment
of an Internet naming protocol required uniform and consistent
application of technical and policy standards enabling interoperability
and system-wide confidence. As would be required for enforcement in a
privately governed SCMS, ICANN uses a binding Registry Agreement as the
enforcement mechanism through which it ensures that its policy and
technical standards are applied Internet-wide. Like the SCMS ecosystem
or ``industry,'' the Internet ``industry'' involves numerous
commercial, academic, geopolitical, and other private and public
stakeholders involved in a broad range of Internet-related functions,
the success of which requires system-wide, coordinated governance. As
would be likely in the SCMS context, ICANN was developed and operates
on a foundation of the fundamental principles of security, stability,
resiliency, multi-stakeholder participation, openness, fairness and
robust completion. Additionally, as detailed in the ICANN MOUs, after a
period of direct government oversight and funding, the privatized
functions governed and coordinated by ICANN were designed to be
financially self-sufficient (i.e. financed by fees paid for services).
    We agree with Dura and the VIIC that ICANN's organizational
structure could translate well to a potential V2V SCMS governance
model. The details of ICANN's mission, core values, powers,
responsibilities, governing principles and procedures are set forth in
its Articles of Incorporation, Bylaws, Charter, and other publicly
available documents. In accordance with those documents, ICANN is
governed by the binding decisions of a Board of Directors, consisting
of both voting Directors and non-voting liaisons. The voting Directors
consist of members selected by a functionally and regionally diverse
nominating committee that reflects the diversity of Internet ecosystem,
as a whole: the Address-Supporting Organization (ASO), the Country-Code
Names Supporting Organization (CCNSO), the Generic Names Supporting
Organization (GNSO), the At-Large Community and the President ex
officio. Directors may not be officials of countries or multinational
geo-political entities. Only ICANN's President can be both a Director
and ICANN employee. Non-voting liaisons are a means for the Board to
obtain input from world-wide governments, through the Government
Advisory Committee (GAC), and three function-specific expert
committees, the Internet Engineering Task force (ETF), Security and
Stability Advisory Committee (SSAC) and Root Server System Advisory
Committee (RSSAC). The organization has an Ombudsman appointed by the
Board to act as a neutral dispute resolution practitioner and provide
an independent internal evaluation of complaints by members of the
ICANN community who believe that the ICANN staff, Board or an ICANN
constituent body has treated them unfairly.
    NHTSA also found quite instructive the procedures used by the
Department of Commerce to effectuate the process of successfully
privatizing certain Internet-related functions. In July 1997, the
Department of Commerce first published a Request for Comments on behalf
of an interagency working group examining the appropriate future role
of the Federal government in the DNS and other issues related to the
administration of the DNS. The following year, in early 1998, based on
the 1400 pages of comments it received to its Request for Comments, it
issued a rulemaking notice proposing certain actions designed to
privatize the management of Internet names and addresses in a manner
that allowed for the development of robust competition and facilitates
global participation in Internet management.\225\ The proposed
rulemaking addressed a variety of issues relating to DNS management
including private sector creation of a new not-for-profit corporation
(the ``new corporation'') managed by a globally and functionally
representative Board of Directors. The rulemaking proposed, among other
things, the new corporation's authorities, detailed the role of the
federal government in policy oversight during the transition,
identified funding, and contained a detailed proposed governance
structure (specific to the number of seats on the Board of Directors)
with substantive stakeholder participation and openness requirements.
The rulemaking explained that, the new corporation would:
---------------------------------------------------------------------------

    \225\ http://www.gpo.gov/fdsys/pkg/FR-1998-02-20/html/98-4200.htm (last accessed Dec. 8, 2016).

    Act much like a standard-setting body. To the extent that the
new corporation operates in an open and pro-competitive manner, its
actions will withstand antitrust scrutiny. Its standards should be
reasonably based on, and no broader than necessary to promote its
legitimate coordinating objectives. Under U.S. law, a standard-
setting body can face antitrust liability if it is dominated by an
economically interested entity, or if standards are set in secret by
a few leading competitors. But appropriate processes and structure
will minimize the possibility that the body's actions will be, or
will appear to a court to be, anti-competitive.\226\
---------------------------------------------------------------------------

    \226\ http://www.ntia.doc.gov/files/ntia/publications/022098fedreg.txt, at page 8818 (last accessed Dec. 8, 2016).

    Later the same year, in July 1998, the Department of Commerce opted
to proceed with privatizing management of the internet DNS not through
rulemaking but by issuing a Statement of Policy expressing the
Government's intent to ``recognize, by entering into agreement with,
and to seek international support for, a new, not-for-profit
corporation formed by private sector Internet stakeholders to
administer policy for the Internet name and address system.'' \227\ In
a July 7, 2000 report,\228\ the GAO confirmed the appropriateness of
the Department of Commerce's actions. The GAO determined, among other
things, that:
---------------------------------------------------------------------------

    \227\ See https://www.ntia.doc.gov/federal-register-notice/1998/statement-policy-management-internet-names-and-addresses (last
accessed Dec. 8, 2016).
    \228\ See Department of Commerce: Relationship with the Internet
Corporation for Assigned Names and Numbers, July 7, 2000 (B-284206)
http://www.gao.gov/new.items/og00033r.pdf (last accessed Dec. 8,
2016).
---------------------------------------------------------------------------

     Department of Commerce had the authority to support
privatization of the DNS on the basis of its general authority \229\ to
foster, promote, and develop foreign and domestic commerce and NTIA's
more specific authority to coordinate the telecommunications activities
of the executive branch; \230\
---------------------------------------------------------------------------

    \229\ In so doing, GAO noted that ``there is no explicit
legislation requiring the government to exercise oversight over the
domain name system.'' Id at 3.
    \230\ 47 U.S.C. 902(b)(2)(H).
---------------------------------------------------------------------------

     The APA notice and comment requirements did not apply to
the Department of Commerce's general statement of policy, as it
contained not substantive regulatory requirements but a general
framework for privatizing the DNS;
     Establishment of ICANN by the private sector was not
subject to the Government Corporation Control Act or various other
legal requirements applicable to entities that are part of or
controlled by the Federal Government;
     Department of Commerce had authority to enter into the
MOUs,

cooperative agreements and sole source contracts with ICANN based on
its general legal authority to work with and enter into these types of
agreements with non-profit entities.
    It must be noted that the circumstances that led to creation of
ICANN are different, in significant respects, than those that now
necessitate the creation of an SCMS to support V2V DSRC communications.
When it issued its Policy Statement, Department of Commerce had funds
dedicated to administration of the DNS it sought to privatize and
already had taken on responsibility for performing that function, in
accordance with Federal law. For this reason, the Department of
Commerce had a legal obligation closely to oversee ICANN's assumption
of responsibility for the DNS during a transition period. It also
continued to fund ICANN in the performance of certain additional
functions previously performed by IANA, even after it ceased to oversee
ICANN's policies and operation of the DNS in 2009. By contrast, to
date, NHTSA has not assumed responsibility for carrying out any
security functions relative to mandated automobile equipment, so no
infrastructure or funding for this purpose now exists. Additionally,
NHTSA seeks not to privatize existing federal security functions or
infrastructure, but to work closely with public and private V2V
stakeholders to take the technical design, intellectual property and
body of policy developed through DOT's SCMS research and facilitate the
creation of a new operational entity--a National SCMS to support V2V,
V2I, and V2X DSRC communications.
    Despite these differences, NHTSA believes that ICANN serves as a
strong comparative industry model of how NHTSA can work with
stakeholders in the SCMS ecosystem to facilitate creation and support
of a multi-stakeholder private sector entity to govern and coordinate
operation of the V2V SCMS.
(d) Potential SCMS Implementation Model
    It is clear that there are numerous different paths that government
and private stakeholders theoretically could follow in implementing a
National SCMS to support the V2V ecosystem--paths the organization,
governance and financial viability of which DOT expects its expanded
policy research to develop and assess. There may even be other viable
security models that could provide sufficient confidence and consumer
privacy protection to V2V messages. However, if NHTSA mandates V2V
communications equipment in light motor vehicles and moves forward with
implementing the SCMS technical design described above, the agency
believes that one promising path was that pursued by Department of
Commerce when it spurred private sector establishment of ICANN.
Specifically, DOT could facilitate the creation of a multi-stakeholder
entity capable of governing and coordinating operation of a National
SCMS. DOT's expanded policy research, including stakeholder input,
modeling, and prototyping of potential governance models, as well as
comments on the NPRM, will help determine whether such an SCMS should
be a purely private entity in which DOT plays an advisory role--or
whether the Federal government should assume control over some critical
SCMS functions (for example, ownership of the definitive root).
    The process followed by the Department of Commerce as it privatized
certain DNS functions could be a useful roadmap for how NHTSA might
work with the private sector to establish a new, multi-stakeholder
entity to take on governance and coordinate operation of a V2V SCMS.
NHTSA's 2014 ANPRM, V2V Readiness Report and SCMS RFI could be viewed
as the first steps in this process. NHTSA used the input the agency
received in response to these public documents, in meetings with RFI
respondents, and through SCMS policy research performed by the VIIC and
others, to expand the scope its planned SCMS governance and policy
research discussed in Section V.B.6. This critical SCMS policy research
is intended to give DOT a central role in, and direct control over,
development of draft policies, procedures and standards that could the
basis for governance of a National SCMS, including draft a Certificate
Policy, Certificate Practice Statement, Registration Agreements, and
Privacy Policy. Another central aspect of DOT's planned SCMS policy
research will be working with PKI and organizational consultants and
stakeholders to prototype a multi-stakeholder governance structure
(much like ICANN's Board of Directors) capable of satisfying the needs
of the broad range of diverse participants in the SCMS ecosystem. If
successful, this prototype could serve as a model for a private sector
entity that could establish and oversee a deployed National SCMS.
    If appropriate based on the Department's planned research, DOT then
could issue a draft V2V SCMC Policy Statement describing a process
(similar to that followed by DOC and ICANN) by which the Department
could, if it chooses to, work collaboratively with a new multi-
stakeholder private entity to develop the binding policies and
technical standards required for stable and sustained operation of a
V2V SCMS. After an initial period of joint policy development and
direct DOT oversight under contract, prior to full SCMS deployment, DOT
gradually could terminate some or all its oversight of the new entity's
activities, completing the transition of authority prior to full SCMS
deployment. Thereafter, representatives of NHTSA and other Federal
government agencies, both within DOT (DOT-R, FHWA, FMCSA, and the
others) and elsewhere in the Federal Government (FCC, FTC), could serve
in an advisory capacity on a Government Advisory Committee or as
nonvoting SCMS Manager Board Members.
(e) SCMS Proof-of-Concept Operational Model Development Plan
    As a result of a better understanding obtained from operating the
prototype security system during Model Deployment, as well as feedback
from the SCMS Request for Information, ITS-JPO and NHTSA realized that
expanding to a National level SCMS would require an intermediate step.
Specifically, that additional research was required to prove the
concept and develop a SCMS working model that allows for investigating
the full range of technical, policy, and organizational elements
involved in deploying and operating the SCMS. Investigating these
components includes providing security certificate management services
to continuing vehicle communications research activities and early
deployments.
    As part of developing a working SCMS model, DOT will:
     Develop and implement a proof of concept SCMS (the SCMS
PoC) that is fully representative of the Final SCMS design, and which
will provide certificate management services to early deployments and
demonstrations, including but not limited to CV pilots,
     Act as the overall SCMS PoC Manager, including developing
policy and procedures that will govern the interactions between the
various entities involved in the V2X eco-system, and
     Based on stakeholder input, will advanced and adapt SCMS
PoC policies and protocols such that they would represent possible
policies and protocols suitable for the establishment and operations of
a SCMS that could support a national deployment of vehicle
communication technology.

    The SCMS proof-of-concept (PoC) will be fully representative of a
production SCMS in terms of functionality, features, and capabilities.
It will support all certificate management ``use-cases'' envisioned for
a production system, and incorporates all elements of the final design
developed by DOT and its industry partners. While not intended to be
``full-scale'', the SCMS PoC will be capable of servicing up to 17
million vehicles annually. The SCMS PoC is being developed to:
    1. Support end-to-end testing of the certificate management use-
cases thus demonstrating feasibility and practicality of system;
    2. Demonstrate the extensibility of the SCMS design (multiple non-
central components);
    3. Support scalability testing through modeling, simulation, and
real-world deployments;
    4. Support integrity, robustness and system vulnerability testing;
    5. Will be used in actual connected vehicle operations by servicing
a variety of early deployments and demonstrations including the
Connected Vehicle pilots (Tampa, NYC, Wyoming), the Smart City
Challenge program recipient, as well as other government sponsored
(state & local) and private sector deployments that we anticipate
emerging over the next several years; and
    6. Will be able to support future connected vehicle application
demonstrations programs for FMCSA, FTA, and FRA (e.g., wireless
roadside inspections; electronic credentialing; grade-crossing safety;
transit-pedestrian safety; and other applications).
    NHTSA and its industry partners (CAMP) are currently in the process
of prototyping an SCMS system that is capable of executing all the core
use-cases associated with the security certificate management life
cycle including enrollment, certificate generation, certificate request
and fulfillment, and revocation. This proof-of-concept SCMS (the SCMS
PoC) is being developed to support real-world operations of early V2V
deployments at connected vehicles pilots sponsored by DOT (in Florida,
New York City, and Wyoming and elsewhere). NHTSA and its industry
partners will continue to refine, test and mature the design of the
SCMS--including addressing the functions and features listed above--by
leveraging this prototype environment. To support these refinement
efforts, we are establishing multiple instantiations of the SCMS
including Production, Quality Assurance and Development environments.
Further, we are in the process of retaining an additional (in addition
to MITRE) independent cyber-security testing and evaluation Team to
conduct a thorough design review on the Final SCMS design, and to
complete focused penetration testing and vulnerability discovery on the
actual SCMS prototype by leveraging the Development environment
platform.
    DOT will develop, operate, and manage the SCMS PoC through multiple
contract/agreements with multiple entities, illustrated via Figure 1.
Figure 1 identifies five research activities including the SCMS PoC
Governmental Management that represent the SCMS PoC Manager
Environment. This environment depicts the boundaries of the SCMS PoC
Governmental Management activities. DOT has already established an
agreement that is currently developing an initial prototype of the SCMS
PoC that will be the basis for the operational environment and support
ongoing functional (refinement) development. SCMS PoC Governmental
Management includes the development of policies that support the
technical processes and procedures and the organizational protocols
that establish interfaces (communications) between entities that
support policy and operational execution. DOT, with the support
provided by the Governmental Management contractor, will be the SCMS
Manager and set policies and protocols that will address threats in
relation to access and change authority. The SCMS Manager will develop
and establish a Certificate Policy and Certificate Practice Statement
that sets the policies and protocols that must be accepted and followed
to be approved to participate in the SCMS environment.
    A separate agreement will establish the operational SCMS PoC
(provides the technical functions that enables generation, distribution
and monitoring of SCMS security materials). Related to the separate
agreement that establishes PoC operations is an agreement that provides
for the technical management that encompasses the development and
documentation of technical process and procedures end entities will use
to initialize devices and obtain security materials. Another contract
will provide Connected Vehicle Support Service that supports the
initial interactions regarding end entity applications for device
initiations, technical support questions, and questions about policies
and procedures. The Connected Vehicle Support contractor will establish
and operate the initial interface with end users.
    Beyond the SCMS PoC manager environment, the SCMS PoC Governmental
Manager will in most cases indirectly interface with other research
activities such as the CV Pilots, and other support entities that
include Certification Service entities, and Device Suppliers. The most
direct outside relationship will be with the National SCMS Prototype
Policy Development research. The SCMS Governmental Management effort
will need to interface with the National SCMS Prototype Policy
Development research to support national level SCMS prototype policy
development.
    The SCMS PoC environment, together with the connected vehicle pilot
sites sponsored by DOT, will provide an opportunity to refine the SCMS
Manager concept and other non-technology related policies and
procedures needed to address security threats.
(f) SCMS Request for Comment
    NHTSA has invested considerable resources and effort in refining
and maturing the Security Credential Management System Design. The
Agency has enlisted the assistance of leading PKI experts in developing
the design, and the design has been formerly reviewed by MITRE
Corporation (see Section V.B.3 for summary of MITRE review) and other
Federal Agencies including DARPA and NIST have also reviewed the
design. NHTSA believes that the SCMS concept and design offers a
practical, efficient and effective means for addressing the need for
confidence in V2V and V2I communications--while simultaneously
addressing privacy concerns arising from potential vehicle tracking
using V2V communications. Nevertheless, a fully representative
prototype of the SCMS system has not yet been developed and tested,
although NHTSA and the JPO are in the process of doing just that, (see
Section V.B.6.e) for details).
    In addition, the SCMS concept calls for periodic (or routine)
communications between the vehicle and various certificate management
entities (which reside in the ``infrastructure'' on the internet) to
execute a variety of certificate management life-cycle services
including: re-provisioning of on-board pseudonym certificates;
distribution of certificate revocation lists; and potential a component
for sending misbehavior detection reports from vehicles to the
Misbehavior Authority of the SCMS as described in the Proposal. While
NHTSA believes that such periodic vehicle to infrastructure
communications can readily be accommodated thru either V2V DSRC
communications (using roadside units, or RSUs), or through the rapidly

increasing connectivity of vehicles using commercial wireless services
(cellular or satellite services that are either integrated into vehicle
or made available through links with an operator's cell phone), NHTSA
nevertheless recognizes that security certificate management concepts
that inherently minimize the need for such periodic V2I communications
may offer advantages relative to maintaining proper on-board
certificate credentials.
    To manage the normal risk associated with any new and complex
information security system, and to address a means for potentially
reducing the need for V2I security communications, NHTSA has been, and
continues to investigate alternatives to the SCMS concept.
    NHTSA seeks comments on all aspects of the SCMS. In technical
design, development, and potential deployment, including DOT's proposal
to expand its governance role in development of a viable organizational
model and policies and procedures applicable to a National SCMS, and
the use of ICANN as a possible roadmap for how to facilitate
establishment of a private, multi-stakeholder entity to manage and
oversee operation of the National SCMS.

C. Vehicle Based Security System (VBSS)

    In late 2012 NHTSA began investigating a certificate management
concept termed the ``vehicle based security system'' (VBSS). VBSS is
based on principals associated with Group Manager concepts for managing
cryptographic materials--and adapted for vehicular application by NHTSA
engineers.
    The major difference between SCMS and VBSS is in generating short-
term certificates. The SCMS approach relies on individual vehicles to
periodically request pseudonym certificates from infrastructure-based
entities, (most notably a Pseudonym Certificate Authority, or PCA)
which in turn generates and signs short-term certificates. Vehicles
then download batches of certificates which are used to digitally sign
BSM messages. In contrast, the VBSS concept calls for delegating this
authority to individual vehicles, and as a result the communications
with the infrastructure are reduced.
    DOT funded a Feasibility Study of the VBSS concept in 2014
(completed by Oakridge National Laboratory, ORNL) and the first phase
of study was completed in December, 2015.\231\ Figure X depicts a high
level comparison of the VBSS and SCMS architectures.
---------------------------------------------------------------------------

    \231\ ``Vehicle Based Safety Systems: A Feasibility Study:
December 23, 2015, ORNL.
[GRAPHIC] [TIFF OMITTED] TP12JA17.016

    Under the VBSS concept, the Pseudonym Certificate Authority (PCA),
Registration Authority (RA), Linkage Authorities (LAs) and Request
Coordination, that are fundamental components in SCMS, are eliminated.
VBSS establishes a Group Manager/Group Managers (GM) to provide
credentials that make it possible for each vehicle to act as a
certificate authority--an entity that can generate short-term
certificates.
    Each vehicle is a member of a group and is assigned a unique
membership secret, a signing key. All member signing keys for a
particular group are associated with a single group certificate. A
vehicle generates its own ephemeral pseudonym certificates by signing
the public key from a self-generated key pair with its group signing
key; vehicles act as subordinate Certificate Authorities and pseudonyms
are generated on demand based on travel requirements. Pseudonym
verifiers use the group certificate to authenticate the pseudonym
certificate,

and then the pseudonym certificate to verify safety messages. The
pseudonym generator remains anonymous, since the receiver uses a single
group certificate to authenticate signatures made by all members from a
particular group. Groups are managed by one or more infrastructure-
based authorities. Members may be removed from groups by distributing
information that allows participants to update their group credentials;
this provides a means to revoke misbehaving vehicles since the
pseudonyms they create will no longer be authenticated by vehicles that
have updated their group credentials.
    Use of pseudonyms (short-lived identifiers) and separation of
distributed identifiers are the primary means of achieving an
acceptable level of privacy. Within a VBSS, how groups are designed
will also affect the preservation of individual privacy. As the number
of distinct groups increases within a geographical area, privacy
protection decreases; if every vehicle within a geographic area were in
its own group (the extreme case); the group identifier becomes a unique
vehicle identifier. This situation can be mitigated by ensuring group
diversity is minimized regionally.
    Misbehavior detection and reporting, and revocation are maintenance
operations that are common to both SCMS and VBSS. There are misbehavior
reporting alternatives discussed in SCMS security section of this
proposal. In relation to misbehavior and revocation, VBSS may offer
some advantages relative to managing communications associated with
revoked vehicles. With SCMS, as the number of revoked vehicles grows--
including those vehicles revoked because they are at the end of their
useful life, the CRL list must also grow. NHTSA and its industry
partners are investigating mechanisms for managing the size the CRL but
nevertheless remains a challenge. With VBSS, instead of sending out
CRLs to revoke vehicles, a Group Broadcast (GB) distributes group
credential updates to participating vehicles; this occurs when a
sufficient number of vehicle misbehavior reports have been validated
resulting in one or more revocations; otherwise, group credentials do
not change. With comparison to the SCMS using CRL list to remove
compromised devices from the V2V communication system, the size of CRL
will increase with the number of compromised devices, VBSS revocation
mechanism's advantage is that the size of group credential updates will
not increase with the number of compromised devices.
    The Phase I study of VBSS and comparisons with other approaches
suggests VBSS is feasible because group-based credentials provide a
means to delegate infrastructure-based operations to vehicles in an
effective way while facilitating the basic requirements of
authentication, privacy, and maintenance of confidence. However, while
Group-based signature schemes are an active area of research they are
evolving and much less mature than other cryptographic systems. For
this reason, VBSS remains in its preliminary stages.
    NHTSA is continuing its research of the VBSS concept and is
beginning a Phase II research Study in 2016. This work will focus on
modeling a Group Manager and enhancing our understanding of the Group
Manager software engineering requirements. NHTSA seeks comment on the
viability of the VBSS certificate management approach including
potential advantages and disadvantages relative to the SCMS approach.
Specifically, we seek comment on the following:

--Could requirements to update an entire group's credentials (to enable
revocation of selected vehicles) actually increase V2I communications
during early deployment (versus distribution of a CRL)?
--Are there CRL distribution schemes that could limit, or otherwise
manage, the growth of the CRL--particular as vehicles reach the end of
their life and are place on the CRL?
--How will requirement to self-generate short-term certificates onboard
the vehicle impact processing and memory requirements onboard the
vehicle--as well as the need to provide high integrity hardware
security modules to support such operations?

D. Multiple Root Authority Credential Management

    U.S. DOT research, performed in partnership with European,
Australian, and Japanese partners, has recognized that the world will
evolve into a multi-root world and that crypto-agility will be a
required capability as a response to increasing cybersecurity
attacks.\232\
---------------------------------------------------------------------------

    \232\ This work and its outcomes are described at: https://ec.europa.eu/digital-single-market/news/harmonized-security-policies-cooperative-intelligent-transport-systems-create-international.
---------------------------------------------------------------------------

    While these capabilities are not required at the initiation of a
connected, cooperative environment, they are useful technical and
policy constructs to incorporate as the threat profile shifts and as
the operational environment grows.
    There are three potential paths to consider, all with advantages
and disadvantages (we further note that these paths are not exclusive
and that as the technologies evolve, they may converge):
    (1) There is the path of establishing a single chain to the Root
Authority that allows for devices/equipment or operational entities to
become enrolled and implicitly trusted by the system. In such a system:
    a. The Root Authority requires a significant level of security to
ensure that it is not comprised.
    b. The root authority can authorize intermediate certificate
authorities which can support a diversity of operational parameters.
However, all intermediate certificate authorities under a single root
authority must operate with the allowable policies of the root
authority.
    c. There is a requirement for a mechanism to manage root
authorities which is capable of transitioning the fundamental
cryptographic elements if the Root Authority is compromised. This
mechanism must be similarly as highly secured as the root authority and
has the ability to revoke the compromised root and add a new root in a
controlled and efficient way for all participants in the security
system.\233\ While allowing for some diversity of operational usage
within the policies of the root, there is a minimum of interfaces
between the root and other nodes, consequently, the threat surface
remains smaller.
---------------------------------------------------------------------------

    \233\ See Root Elector System Design at http://www.mycreativeregistry.net/IPCOM/000245336 (last accessed Dec 4,
2016).
---------------------------------------------------------------------------

    d. The mechanism for managing the root, although requiring (and
incurring costs for) a high level of security, allows for orderly
migration of the security system to incorporate root replacements and
cryptographic improvements (as long as the devices within the system
are capable of adopting such new cryptographic processes), thus future-
proofing the overall system to the extent possible within known
parameters.
    This is the path that the US is taking to establish initial
operations to support emerging connected vehicle environments.
    (2) There is the path of establishing multiple, co-existing roots
in which each Root Authority must have an agreement with other root
authorities that describe an appropriate level of trust. Based on the
trust level, a host of interfaces have to be enacted for data transfer
that assures one operational root that the other operational root
remains trusted. See the report titled,

``Cooperative-ITS Credential Management System Functional Analysis and
Recommendations for Harmonization Document HTG6-4 Version: 2015-09''
\234\ for greater details on the trust levels and how to enact the
trust levels from both a policy perspective as well as a data flow
perspective.
---------------------------------------------------------------------------

    \234\ http://ec.europa.eu/newsroom/dae/document.cfm?action=display&doc_id=11398.
---------------------------------------------------------------------------

    A benefit to this path is that with multiple operational roots, if
one is compromised, another root could potentially take over operations
(although this is highly dependent upon the trust levels--if the other
operating root that has to take over does not trust the credentials of
the compromised root (even if the credentials in use are still valid
and not compromised), then all actors enrolled in the compromised root
will have to cease operations of the cooperative applications until
they can be proven to be trusted actors and enrolled in the
uncompromised root authority).
    Understanding the different trust levels is the key to
understanding whether there are benefits to a multiple root world. A
key conclusion to the analysis on how to enact different trust levels
is that adding even one additional root to the system increases the
number of interfaces among entities which exponentially increases the
attack surface of the inter-related systems. This model also increases
costs of running different organizations, increases the costs
associated with data analysis, and increases the costs of auditing and
updating policies. In addition, it seems that agreement of common
security policies under the initialization of parallel operational
roots, operated by different organizations with different priorities,
is likely to be very difficult, adversely affecting the level of trust
that may be established among various root authorities.
    Furthermore the Government will have no authority to compel one
Root Authority to interface with another Root Authority. This would
adversely affect interoperability given the equipment under the
different roots would not interact in crash avoidance situations
reducing the effectiveness of V2V. For example a group of OEMs could be
covered under one Root Authority were as a group of aftermarket
suppliers could be covered under a different Root Authority. If the OEM
group decides that the aftermarket devices do not meet the OEM level of
performance then no agreement would be implemented and equipment in the
OEM group would not interact with equipment in the aftermarket group.
This could create market disparity and reduce consumer choice.
    (3) There is one additional path that is very similar to path #2,
but also incorporates the use of different types of security
credentials (or security certificates). The use of the NIST elliptical
curve SHA-256 offers a significant advantage over other types of
credentials in that it includes the lowest amount of overhead for an
appropriate level of trust and authentication among vehicle moving at
very high speeds.
    This version of the model would allow for different credentials
(such as ``brainpool'' or other curves) to also be used in operations.
This version of the model significantly increases the complexity of the
system. While it offers greater crypto-flexibility, having the ability
to recognize and use different credentials will require that ALL
equipment/devices/applications will have to be able to recognize and
trust messages created with either type of credential in order to
ensure continued interoperability. This path may increase the cost and
complexity of equipment on the vehicle and/or change the nature of the
equipment, as the receivers will have to recognize the different
cryptographic technologies and perform additional/different validity
checks for the different cryptographic technologies. Also, this
capability/path is not yet proven and would need to be demonstrated
under a number of conditions to ensure that the transactions and timing
can still meet the safety applications requirements for latency of the
exchange and scalability of the dedicated spectrum available for low-
latency communications, such as the V2V Basic Safety Message.
    This is the path that is under consideration within the European
Union at this time.
    All of these paths are, in some sense, multi-root in that it is
necessary to have at least a back-up root as part of an internal
system. The analysis of the different paths highlights some of the key
issues that will need to be addressed as the future evolves:
     Security credentials: At some point, we can expect that
the security credentials based upon the current cryptographic level
will be broken due to quantum computing and that new security
approaches and/or new cryptographic curves will be needed. Research is
needed into new curves to ensure that new security approaches do not
significantly increase the communications overhead in order support the
latency requirements for V2V communications.
     Governance/Certificate Policies: New root management and
recovery solutions will need to be developed as the initial, smaller
connected vehicle environments evolve into more complicated, region-
wide, overlapping environments that may operate at different levels of
security. This has been addressed in the first path through the
innovative creation of Root Electors that provide the ability to revoke
a compromise Root and establish a new Root without having to re-
initialize devices.\235\
---------------------------------------------------------------------------

    \235\ See Root Elector System Design at http://www.mycreativeregistry.net/IPCOM/000245336 (last accessed Dec. 4,
2016).
---------------------------------------------------------------------------

VI. What is the agency's legal authority to regulate V2V devices, and
how is this proposal consistent with that authority?

A. What can NHTSA regulate under the Vehicle Safety Act?

    NHTSA has broad statutory authority to regulate motor vehicles and
items of motor vehicle equipment under the National Traffic and Motor
Vehicle Safety Act (the ``Safety Act'').\236\ As applied in this
context, the agency's authority includes all or nearly all aspects of a
V2V system. Congress enacted the Safety Act in 1966 with the purpose of
reducing motor vehicle crashes and deaths and injuries that occur as a
result of motor vehicle crashes and non-operational safety hazards
attributable to motor vehicles.\237\ The Safety Act, as amended, is now
codified at 49 U.S.C. 30101 et seq.
---------------------------------------------------------------------------

    \236\ For more discussion and analysis of NHTSA's authority to
regulate advanced crash avoidance technologies, including V2V
technologies, under the Safety Act, see the Potential Regulatory
Challenges of Increasingly Autonomous Vehicles, 52 Santa Clara L.
Rev. 1423 (Wood et al., 2012) at http://digitalcommons.law.scu.edu/lawreview/vol52/iss4/9/ (last accessed Dec. 6, 2016).
    For example, the agency's authority to address the privacy and
security of vehicle data associated with the operation of those
technologies is discussed at length. Id., at pp. 1448, 1465-72.
Addressing data security is necessary to safeguard the effectiveness
of these technologies and promote their acceptance by vehicle users.
Addressing privacy is similarly necessary to promote public
acceptance. The views expressed in that article fairly encompass the
agency's views of its regulatory authority.
    \237\ H.R. Rep. No. 89-1776, at 10 (1966).
---------------------------------------------------------------------------

    The vehicle technologies that enable vehicles to send messages to
and receive messages from each other are vastly different from those
that existed when the Safety Act was enacted. Then, the vehicle
operating systems were largely mechanical and controlled by the driver
via mechanical inputs and linkages. Components and systems were either
designed into the vehicle at the time of original manufacture or were
later

attached to or physically carried into the vehicle. Sensing of a
vehicle's performance and the roadway environment was done solely by
the driver.
    Today, in contrast, an increasing number of vehicle functions are
electronic. These functions can be activated and controlled
automatically and do not necessarily require driver involvement, unlike
the mechanical functions of previous generations of vehicles. V2V
technologies require no driver involvement in order to send and receive
information that can be used for vehicle safety functions. Other ways
in which V2V technologies differ from the mechanical technologies
prevalent when the Safety Act was first enacted include the fact that
how they operate can be substantially altered by post-manufacture
software updates, and that advances in communications technology make
it possible for nomadic devices with vehicle-related applications to be
brought into the vehicle.
    The language of the Safety Act, however, is broad enough to
comfortably accommodate this evolution in vehicle technologies. NHTSA's
statutory authority over motor vehicles and motor vehicle equipment
would allow the agency to establish safety standards applicable both to
vehicles that are originally manufactured with V2V communications
devices, and to those devices added after original manufacture.
    In the Safety Act, ``motor vehicle'' is defined as a ``vehicle
driven or drawn by mechanical power and manufactured primarily for
use'' on public roads.\238\ The definition of ``motor vehicle
equipment,'' as cited below, is broader and thus effectively
establishes the limit of the agency's authority under the Safety Act:
---------------------------------------------------------------------------

    \238\ 49 U.S.C. 30102(a)(6).
---------------------------------------------------------------------------

    (A) Any system, part, or component of a motor vehicle as originally
manufactured;
    (B) any similar part or component manufactured or sold for
replacement or improvement of a system, part, or component, or as an
accessory or addition to a motor vehicle; or
    (C) any device or an article or apparel, including a motorcycle
helmet and excluding medicine or eyeglasses prescribed by a licensed
practitioner, that--
    (i) is not a system, part, or component of a motor vehicle; and
    (ii) is manufactured, sold, delivered, or offered to be sold for
use on public streets, roads, and highways with the apparent purpose of
safeguarding users of motor vehicles against risk of accident, injury,
or death.\239\
---------------------------------------------------------------------------

    \239\ Section 30102(a)(7)(C); MAP-21, Public Law 112-141, sec.
31201, 126 Stat. 405. Congress added subparagraph (C) to the
statutory definition of ``motor vehicle equipment'' in 1970 when it
amended the definition in order to clarify the Department's
authority over additional objects such as motorcycle helmets. See S.
Rep. No. 91-559, at 5 (1970). However, Congress did not seek to
limit the extension of the Department's authority only to motorcycle
helmets and instead utilized the broad terms ``device, article, and
apparel'' to describe the universe of objects that are within the
agency's authority. See id. Acknowledging the concerns of those who
authored the House version of the amendatory language that utilizing
the terms ``device, article, and apparel'' might unduly extend the
Department's authority to objects that have only a tangential
relation to motor vehicle safety, the conference committee added a
use restriction. See id. Congress relaxed this use restriction in
the statutory definition of ``motor vehicle equipment'' as part of
the amendments to the Safety Act in MAP-21. See MAP-21, Public Law
112-141, sec. 31201, 126 Stat. 405. Thus, the Department's
regulatory authority under subparagraph (C) is limited to those
devices, articles, or apparel that are used for ``the apparent
purpose of safeguarding users of motor vehicles against risk of
accident, injury, or death.'' See id. (Emphasis added.)
---------------------------------------------------------------------------

    NHTSA's authority over these groups of items--(1) systems, parts,
and components installed or included in a vehicle, (2) replacements and
improvements to those systems, parts, and components, (3) accessories
and additions to motor vehicles, and (4) devices or articles with an
apparent safety-related purpose--is very broad. The status of these
items as motor vehicle equipment does not depend on the type of
technology or its mode of control (mechanical or electronic), or
whether an item is tangible or intangible. The transition from
mechanical to electromechanical systems has thus had no effect on the
extent of NHTSA's authority over motor vehicle performance. NHTSA has
regulatory authority under the Safety Act over all the systems, parts,
and components installed on new motor vehicles, even as motor vehicle
control systems become increasingly electronic, and perhaps
increasingly automated, in the future.
    Put in the context of V2V-related motor vehicle equipment, NHTSA
considers the following items subject to the agency's regulatory
authority:
    (1) Any integrated original equipment (OE) used for V2V
communications or safety applications reliant on V2V communications.
    (2) Any integrated aftermarket equipment used for V2V
communications or safety applications reliant on V2V communications,
under 30102(a)(7)(B), if the equipment ``improves'' an already-existing
function of the vehicle or is an ``addition'' to the vehicle.
    (3) Some non-integrated aftermarket equipment, depending on its
nature and apparent purpose, under 30102(a)(7)(B), if the equipment is
a motor vehicle ``accessory'' (something to be used while the vehicle
is in operation, that enhances that operation), or 30102(a)(7)(C), if
the equipment is a device used for the apparent purpose of traffic
safety (purpose would be clearly observable from the characteristics of
the object and the context of its use, rather than necessarily defined
by the manufacturer's intent for the equipment).
    (4) Software that provides or aids V2V functions, and software
updates to all of this equipment, because, under 30102(a)(7)(B),
updates can be considered as replacements or improvements.
    (5) Potentially some roadside infrastructure (V2I), under
30102(a)(7)(B) and (C), because if its apparent purpose is safety, it
may be an ``accessory'' or a ``device . . . manufactured . . . with the
apparent purpose of safeguarding users of motor vehicles against
accident, injury, or death.'' We currently anticipate that only a small
subset of roadside infrastructure may fall within this category.
    A number of commenters to the ANPRM and Readiness Report raised
issues with the agency's discussion of the bounds of its authority.
While most commenters agreed that the agency has clear authority to
require V2V communications devices in new vehicles and to regulate
aftermarket V2V devices,\240\ the Alliance argued that it appeared that
the agency sought to regulate ``the relationship between the vehicle
manufacturers and their customers,'' \241\ given that NHTSA had
discussed the potential need for additional security certificates
during a V2V communications device's lifetime, as well as the
possibility of software updates as needed. The Alliance argued that the
Safety Act did not authorize a ``lifetime maintenance mandate'' to
cover the potential need to provide additional certificates or software
updates.\242\ Moreover, the Alliance argued, NHTSA could not require
consumers to renew security certificates or accept downloaded
certificates pushed directly to the vehicle, or to ensure that DSRC
remained operable over the lifetime of the vehicle, and therefore a
FMVSS would not be publicly accepted, and therefore inconsistent with
the agency's authority

under the Safety Act, because consumers might not be confident that
DSRC would continue to work properly over the vehicle's lifetime.\243\
The Alliance even suggested that it could violate the Computer Fraud
and Abuse Act (18 U.S.C. 1030) to push new certificates to consumers
without their consent.\244\
---------------------------------------------------------------------------

    \240\ Alliance, at 13, 15.
    \241\ Alliance, at 7.
    \242\ Alliance, at 15.
    \243\ Id, and at 15, 47-48.
    \244\ Alliance, at 15.
---------------------------------------------------------------------------

    In response, NHTSA agrees that we have authority under the Safety
Act to require V2V communications devices in new vehicles and mandate
specific aspects of their performance, and to require similar
performance from aftermarket V2V devices designed to participate in the
V2V system, as long as those standards are consistent with Safety Act
requirements.
    We disagree, however, with the points raised by the Alliance
regarding certificate and software updates. At this time, NHTSA is not
requiring that certificate and software updates be pushed to vehicles
without consumers' consent--we are simply requiring that manufacturers
alert consumers, via a telltale or message center indicator, to the
fact that V2V will not work if they are out of certificates or in need
of some other kind of update, and that devices be capable of receiving
such updates.\245\ Consumers will need to know what action the telltale
or message center indicator is telling them to take in order to
continue to obtain the safety benefits of V2V, so vehicle or device
manufacturers will need to ensure either that the message center
indicator is clear about the needed action and the consequences of not
taking that action, or that the explanation for the message or telltale
is contained somewhere (like the owner's information) where the
consumer can easily find it and understand what to do. Alternatively,
vehicle manufacturers could obtain consumer consent for automatic
certificate and software updates at the time of first sale, although
that consent would not cover subsequent vehicle owners. Even if
manufacturers make it necessary for consumers to consent to each new
download, NHTSA expects that the need to do so would be sufficiently
infrequent and well-explained by vehicle manufacturers in order to
ensure that consumers recognize the significant safety risk of failing
to accept the download. We assume that, at this point in time, nearly
all consumers are already well-accustomed to the need for software
updates on their electronic devices, like computers and smartphones,
and regularly accept and initiate such updates. We seek comment from
manufacturers on how they plan to develop succinct and compelling
explanations to accompany these consent requests that would encourage
consumers to accept the updates in a timely manner. We also seek
additional comment regarding all aspects of consumer consent.
---------------------------------------------------------------------------

    \245\ See Section III.E.13, above.
---------------------------------------------------------------------------

    Alternatively, if manufacturers are concerned that consumers would
not accept new certificate downloads and would thereby lose the safety
benefits of V2V communications, manufacturers could install V2V devices
that are pre-loaded with all the certificates that the device would
need over its lifetime. This approach would presumably necessitate more
storage capacity on the V2V device (and thus more cost), and could also
present a potentially bigger security risk if the device were somehow
compromised. We seek comment on whether requiring devices to come pre-
loaded with a lifetime's worth of certificates could be a better
approach than requiring consumers to consent to (and obtain) new
downloads, and if so, why.
    Besides certificates, however, we expect that software associated
with both the V2V communications device itself, and with any
accompanying applications that rely on V2V communications for
information, would likely need updating during the vehicle's lifetime.
As explained above, as for certificate updates, we are proposing to
require that manufacturers include a means to communicate to the driver
if and when a software update is needed. If the driver then chooses not
to accept the update, the system must continue to warn them that V2V
functionality is not available. If manufacturers choose not to update
software when issues with it are discovered, and safety problems
result, NHTSA may choose to pursue those problems under its enforcement
authority.
    Some commenters disagreed with the agency's statements in the
Readiness Report that our Safety Act authority extended to cover
RSE.\246\ The Alliance argued that RSE only indirectly served a safety
purpose, because they would perform non-safety functions as well, and
therefore could not be motor vehicle equipment. CTIA and others
presented a similar argument regarding the agency's authority to
regulate mobile devices and applications for mobile devices, as it has
elsewhere.\247\
---------------------------------------------------------------------------

    \246\ Alliance, at 7, 16.
    \247\ CTIA in general; TIA at 6; CEA at 2-9; Wi-Fi Alliance at
7.
---------------------------------------------------------------------------

    With regard to the agency's authority under the Safety Act over
RSE, although we are not proposing in this NPRM to regulate any RSEs,
we disagree that a device that performs non-safety functions in
addition to safety functions is necessarily not motor vehicle
equipment. Tires, for example, perform the non-safety function of
helping a vehicle travel down the road by creating friction between the
wheel and the road, but that friction also plays a safety role by
helping the vehicle stop rapidly when the driver hits the brakes.
Brakes and steering wheels, for that matter, help drivers execute turns
which may be necessary to reach their intended destination, but they
also help drivers avoid crashing their vehicles. Many items of motor
vehicle equipment that NHTSA regulates perform safety functions in
addition to being generally necessary for the driving task. NHTSA can
regulate those items insofar as they affect vehicle safety. By
providing a link between the SCMS and the vehicle, and potentially
being the mechanism by which the vehicle's V2V communications device is
able to obtain new security certificates and information about which
other vehicles to trust and not to trust, the RSE may play a vital role
in creating the environment needed for safety. A BSM cannot be sent
without a certificate, and a V2V communications device must not trust
an untrustworthy partner vehicle, or safety applications may not
function properly.
    That said, NHTSA does not currently anticipate the need to specify
requirements for the RSE that may participate in the overall V2V
system. We note that FHWA has already issued specifications for
roadside units that are publicly available,\248\ and at this point, we
would expect the ones participating in the overall V2V system and
interacting with V2V-equipped vehicles to conform to these
specifications, or to updated specifications if and when they exist. We
seek comment on whether additional regulation of RSE/RSU by NHTSA might
be important to ensure that, among other things, they do not collect
information that could be unnecessarily harmful to privacy; pose no
cybersecurity threat to the overall V2V system; or perform (or risk
failing to perform) any other task that could be harmful to vehicles or
the V2V system

or in any way negatively impact safety benefits associated with V2V.
---------------------------------------------------------------------------

    \248\ U.S. DOT Federal Highway Administration, ``DSRC Roadside
Unit (RSU) Specifications Document, Version 4.0, April 15, 2014.''
Available at http://docplayer.net/11087167-Dsrc-roadside-unit-rsu-specifications-document.html (last accessed Dec. 6, 2016).
---------------------------------------------------------------------------

    Thus, the agency believes that our existing Safety Act authority
comfortably allows us to require V2V communications devices in new
motor vehicles and aftermarket equipment. The following section
examines what the Safety Act requires NHTSA to consider in developing
an FMVSS, and how the proposal in this NPRM may meet those
requirements.

B. What does the Vehicle Safety Act allow and require of NHTSA in
issuing a new FMVSS, and how is the proposal consistent with those
requirements?

    Under the Safety Act, NHTSA's motor vehicle safety standards are
generally performance-oriented.\249\ Further, the standards are
required to be practicable and objective, and to meet the need for
safety.\250\ The following paragraphs will discuss briefly the meaning
of each of these requirements, and then explore how the agency believes
that the proposal may meet those requirements.
---------------------------------------------------------------------------

    \249\ 49 U.S.C. 30102(a)(8) (defining ``motor vehicle safety''
as ``the performance of a motor vehicle . . . in a way that protects
the public against unreasonable risk of accidents occurring because
of the design, construction, or performance of a motor vehicle'');
and sec. 30102(a)(9) (defining ``motor vehicle safety standard'' as
``a minimum standard for motor vehicle or motor vehicle equipment
performance''). See also: S. Rep. No. 89-1301, at 2713-14 (1966)
(stating that motor vehicle standards issued by NHTSA should specify
a minimum level of safety performance).
    \250\ 49 U.S.C. 30111(a) (establishing requirements for NHTSA to
follow when issuing motor vehicle safety standards).
---------------------------------------------------------------------------

1. ``Performance-Oriented''
    In the Safety Act, the Secretary is directed to issue motor vehicle
safety standards. ``Motor vehicle safety standards'' are defined as
``minimum standard[s] for motor vehicle or motor vehicle equipment
performance.'' \251\ One point to note at the outset is the party of
whom performance is required: NHTSA's safety standards apply to
manufacturers of new motor vehicles and motor vehicle equipment. It
therefore falls to those ``manufacturers''--from vehicle OEMs to OE
suppliers to aftermarket device manufacturers to creators of V2V safety
applications--to certify compliance with any safety standards
established by NHTSA, and to conduct recalls and remedy defects if
NHTSA finds them.\252\ Vehicle owners are not required to comply with
NHTSA's safety standards, which means that for vehicles already on the
roads, participation in the V2V system would be entirely voluntary:
NHTSA can regulate how aftermarket devices function, but it cannot
require manufacturers or drivers to add them to used vehicles. The one
exception to this rule against retrofit is that NHTSA has authority to
require retrofit of commercial heavy-duty vehicles,\253\ but that is
not part of this proposal on light-duty vehicles.
---------------------------------------------------------------------------

    \251\ Id.; See also: Sec. 30102(a)(9) (emphasis added).
    \252\ 49 U.S.C. 30115(a), ``Certification of compliance; In
general''; sec. 30116, ``Defects and noncompliance found before sale
to purchaser''; sec. 30117(a), ``Providing information to, and
maintaining records on, purchasers; Providing information and
notice''; sec. 30118, ``Notification of defects and noncompliance'';
sec. 30119, ``Notification procedures''; sec. 30120, ``Remedies for
defects and noncompliance.''
    \253\ Per 49 CFR 1.95, which delegates to NHTSA the Secretary's
authority under Sec. 101(f) of the Motor Carrier Safety Improvement
Act of 1999 (Pub. L. 106-159; Dec. 9, 1999) to promulgate safety
standards for ``commercial motor vehicles and equipment subsequent
to initial manufacture.'' NHTSA's retrofit authority is coextensive
with FMCSA's.
---------------------------------------------------------------------------

    While NHTSA is directed to establish performance standards, the
case law and the legislative history indicate that when necessary to
promote safety, NHTSA can be quite specific in drafting its performance
standards and may require or preclude the installation of certain
equipment. The cases have reinforced this concept by determining that
NHTSA is ``generally charged'' \254\ with setting performance
standards, instead of becoming directly involved in questions of
design.\255\ The legislative history further illustrates that NHTSA's
standards are to ``[specify] the required minimum safe performance of
vehicles but not the manner in which the manufacturer is to achieve the
specified performance.'' \256\ An example cited in the legislative
history points to ``a building code which specifies the minimum load-
carrying characteristics of the structural members of a building wall,
but leaves the builder free to choose his own materials and design.''
\257\ In that example, the agency could require the wall to be built
(analogous to requiring certain equipment in vehicles) but would be
expected to measure the wall's regulatory compliance by its performance
rather than its design.
---------------------------------------------------------------------------

    \254\ Washington v. Dept. of Transp., 84 F.3d 1222, 1224 (10th
Cir. 1996) (citations omitted).
    \255\ Id. at 1224 (citations omitted).
    \256\ S. Rep. No. 89-1301, at 2713-14 (1966).
    \257\ Id.
---------------------------------------------------------------------------

    Although the Safety Act directs NHTSA to issue performance
standards, however, Congress understood that the agency may preclude
certain designs through these performance standards. ``Motor vehicle
safety'' is defined in the Safety Act as the performance of a motor
vehicle in a way that protects the public from unreasonable risks of
accident due to (among other things) the design of a motor
vehicle.\258\ The legislative history indicates that this language is
not intended to afford the agency the authority to promulgate design
standards, ``but merely to clarify that the public is to be protected
from inherently dangerous designs which conflict with the concept of
motor vehicle safety.'' \259\ This clarification is evidence that
Congress recognized that performance standards inevitably have an
impact on the design of a motor vehicle.\260\
---------------------------------------------------------------------------

    \258\ Sec. 30102(a)(9).
    \259\ H.R. Rep. No. 89-1919, at 2732 (1966).
    \260\ Courts have also recognized this fact. See Chrysler Corp.
v. Dept. of Transp., 515 F.2d 1053, 1058-59 (6th Cir. 1975); see
also: Washington, 84 F.3d at 1224 (stating ``the performance-design
distinction is much easier to state in the abstract than to apply
definitively-so. . . . This is particularly true when, due to
contingent relationships between performance requirements and design
options, specification of the former effectively entails, or
severely constrains, the latter.'').
---------------------------------------------------------------------------

    The courts have further elaborated on the framework established by
Congress and have recognized that, when necessary to achieve a safety
purpose, NHTSA can be quite specific in establishing performance
standards even if certain designs will be precluded. For example, the
Sixth Circuit found that an agency provision permitting rectangular
headlamps, but only if they were of certain specified dimensions, was
not an invalid design restriction and ``serve[d] to ensure proper
headlamp performance,'' reasoning that ``the overall safety and
reliability of a headlamp system depends to a certain extent upon the
wide availability of replacement lamps, which in turn depends upon
standardization.'' \261\ Thus, the court found it permissible for the
agency to establish very specific requirements for headlamps even
though it would restrict design flexibility.\262\
---------------------------------------------------------------------------

    \261\ Chrysler Corp., 515 F.2d at 1058-59.
    \262\ Id.
---------------------------------------------------------------------------

    Further, the cases indicate that NHTSA can establish standards to
require the installation of certain specific equipment on vehicles and
establish performance standards for that equipment. For example, the
Tenth Circuit found in Washington v. DOT that ``NHTSA's regulatory
authority extends beyond the performance of motor vehicles per se, to
particular items of equipment.'' \263\ In that case, the validity of
NHTSA's FMVSS No. 121 requiring ABS systems on air-braked vehicles was
challenged as ``imposing design specifications rather than

performance criteria.'' \264\ The court's conclusion was based not only
on the fact that prior courts had upheld NHTSA's standards requiring
particular equipment,\265\ but also on the fact that Congress had
recognized NHTSA's former rulemakings and left NHTSA's authority
unchanged when it codified the Safety Act in 1994.
---------------------------------------------------------------------------

    \263\ Washington, 84 F.3d at 1222, 1225 (citations omitted).
    \264\ Id. at 1223.
    \265\ Id. at 1225 (citing Chrysler Corp. v. Rhodes, 416 F.2d
319, 322, 322 n. 4) (1st Cir. 1969) (``motor vehicles are required
to have specific items of equipment . . . These enumerated items of
equipment are subject to specific performance standards,'' including
lamps and reflective devices requiring ``specific items of
equipment'')); Wood v. Gen. Motors Corp., 865 F.2d 395, 417 (1st
Cir. 1988) (``requiring seat belts or passive restraints . . . has
elements of a design standard''); Automotive Parts & Accessories
Ass'n v. Boyd, 407 F.2d 330, 332 (D.C. Cir. 1968) (``factor equipped
. . . head restraints which meet specific Federal standards'').
---------------------------------------------------------------------------

    Thus, in summary, NHTSA is required to issue performance standards
when regulating motor vehicles and motor vehicle equipment. However,
NHTSA is able to be quite specific in establishing performance
standards and may preclude certain designs that are contrary to the
interests of safety. Further, NHTSA may require the installation of
certain equipment and establish performance standards for that
equipment.
    As Section III.E discusses at length and as the regulatory text at
the end of this preamble discusses at length, NHTSA has developed a set
of proposed performance requirements for DSRC performance. These
sections explain: (1) What information needs to be sent to the
surrounding vehicles; (2) how the vehicle needs to send that
information; (3) how a vehicle shows that it is a valid source of
information; and (4) how a vehicle makes sure the prior three functions
work in various operational conditions (i.e., broadcast under congested
conditions, detect/report misbehavior, and obtain new security
materials). The proposal draws from existing voluntary standards while
also explaining why a particular threshold or requirements from a
voluntary standard is appropriate. The proposal contains a mandatory
Privacy Statement, set forth in Appendix A. Finally, the proposal
includes a test method for evaluating many of these aspects of
performance. Having a clear test method helps inform the public as to
how the agency would evaluate compliance with any final FMVSS. While
research is ongoing in a few areas (namely message congestion
mitigation, explicit details for misbehavior detection, SCMS policies
and procedures), we have described for the public the potential
requirements that we are considering for an NPRM and the potential test
methods for evaluating compliance with those requirements. We believe
that the public comments that we will receive in response (coupled with
the agency's ongoing research) will produce a robust record upon which
the agency can make a final decision.
    The provisions allowing alternative technologies to satisfy the
mandate are performance-oriented, but do not specify a particular way
of communicating. The goal of this is to maximize industry's ability to
innovate and potentially employ future communication technologies that
may be able to meet the performance requirements (like, for example,
latency) for V2V-based safety warning applications. While alternative
technologies would be subject to several aspects of the test procedures
set forth for DSRC-based devices, it leaves open for industry to
develop a number of aspects of performance, including interoperability
with all other V2V communications technologies that transmit BSMs. We
believe that the inclusion of some performance tests makes these
provisions consistent with the Safety Act requirement of standards
being ``performance-oriented.'' We seek comment on this tentative
conclusion.
2. Standards ``Meeting the Need for Motor Vehicle Safety''
    As required by the Safety Act, standards issued by the agency must
``meet the need for motor vehicle safety.'' \266\ As ``motor vehicle
safety'' is defined in the statute as protecting the public against
``unreasonable risk'' of accidents, death, or injury,\267\ the case law
indicates that there must be a nexus between the safety problem and the
standard.\268\
---------------------------------------------------------------------------

    \266\ 49 U.S.C. 30111(a).
    \267\ 49 U.S.C. 30102(a)(8).
    \268\ See, e.g., Nat'l Tire Dealers Ass'n v. Brinegar, 491 F.2d
31, 35-37 (D.C. Cir. 1974) (stating that the administrative record
did not support a significant nexus between motor vehicle safety and
requiring retread tires to have permanent labels because there was
no showing that a second-hand owner would be dependent on these
labels and no showing as to how often such situations would arise);
see also H&H Tire Co. v. Dept. of Transp., 471 F.2d 350, 354-55 (7th
Cir. 1972) (expressing doubt that the standard met the need for
safety because there was little evidence that the required
compliance tests would ensure that retreaded tires would be capable
of performing safely under modern driving conditions).
---------------------------------------------------------------------------

    However, a standard need not address safety by direct means. In
upholding NHTSA's authority to issue a safety standard requiring
standardized vehicle identification numbers, the Fourth Circuit Court
of Appeals found that an FMVSS requiring VINs met the need for motor
vehicle safety by such indirect means as reducing errors in compiling
statistical data on motor vehicle crashes (in order to aid research to
understand current safety problems and support future standards, to
increase the efficiency of vehicle recall campaigns, and to assist in
tracing stolen vehicles).\269\
---------------------------------------------------------------------------

    \269\ Vehicle Equip. Safety Comm'n v. NHTSA, 611 F.2d 53, 54
(4th Cir. 1979).
---------------------------------------------------------------------------

    We believe that there is a clear nexus between the safety problem
and the proposals in this document. In the case of DSRC-based devices,
DSRC can enable all of the safety applications under consideration by
the agency, such as Intersection Movement Assist, Left Turn Assist, and
Electronic Emergency Brake Light, which means that DSRC can help to
address the safety problems of, e.g., intersection collisions,
collisions with forward stopped or slowing vehicles, collisions that
occur because a driver chose to pass a forward vehicle without enough
room to do so safely, etc. For some of the other safety applications,
which can also be enabled by other technologies besides DSRC, such as
on-board sensors, radar, or cameras, DSRC can add robustness to an on-
board system. DSRC will either be the sole enabler of some safety
applications or present a possible enhancement to on-board systems with
regard to other applications. In either case, DSRC will address safety
needs.
    Moreover, case law supports that DSRC need not directly create more
safety itself, as long as it is enabling other safety applications. If
VINs could be upheld as meeting the need for motor vehicle safety
simply by virtue of the fact that they aid research in understanding
safety problems and supporting future standards, as well as aiding
recall campaigns and tracking of stolen vehicles, then DSRC, which
would directly enable half a dozen safety applications at its inception
and perhaps many more eventually, seems even more clearly to meet the
need for safety in that respect.
    Non-DSRC devices should have a similar nexus to the safety problem.
3. ``Objective'' Standards
    A standard is objective if it specifies test procedures that are
``capable of producing identical results when test conditions are
exactly duplicated'' and performance requirements whose satisfaction is
``based upon the readings obtained from measuring instruments as
opposed to subjective opinions.'' \270\ The requirement that standards
be stated in

objective terms matches the overall statutory scheme requiring that
manufacturers self-certify that their motor vehicles or motor vehicle
equipment comply with the relevant FMVSSs.\271\ In order for this
statutory scheme to work, the agency and the manufacturer must be able
to obtain the same result from identical tests in order to objectively
determine the validity of the manufacturer's certification.\272\
---------------------------------------------------------------------------

    \270\ Chrysler Corp. v. Dept. of Transp., 472 F.2d 659, 676 (6th
Cir. 1972); see also Paccar, Inc., v. Nat'l Highway Traffic Safety
Admin., 573 F.2d 632, 644 (9th Cir. 1978).
    \271\ 49 U.S.C. 30115(a).
    \272\ Chrysler Corp., 472 F.2d at 675.
---------------------------------------------------------------------------

    Using those two elements of objectivity (capable of producing
identical results and compliance based on measurements rather than
subjective opinion), the Sixth Circuit Court of Appeals found that the
test procedure in question in an early version of FMVSS No. 208 was not
objective because the test dummy specified in the standard for use in
compliance testing did not give consistent and repeatable results.\273\
The court in this case was unconvinced that the standard met the
objectivity requirements even though NHTSA based its test procedure on
a test dummy in a voluntary automotive industry standard (Society of
Automotive Engineers Recommended Practice J963). The court rejected
NHTSA's explanation that, although J963 ``may not provide totally
reproducible results,'' ``dummies conforming to the SAE specifications
are the most complete and satisfactory ones presently available.''
\274\ Further, the court rejected NHTSA's reasoning that, in the event
that the agency's test results were different from those of the
manufacturers because of the difference in the test dummies, NHTSA's
test results would not be used to find non-compliance, stating that
``there is no room for an [ ] agency investigation [ ] in this
procedure'' that enable the agency to compare results of differing
tests.\275\
---------------------------------------------------------------------------

    \273\ As the court stated,
    The record supports the conclusions that the test procedures and
the test device specified . . . are not objective in at least the
following respects: (1) The absence of an adequate flexibility
criteria for the dummy's neck; the existing specifications permit
the neck to be very stiff, or very flexible, or somewhere in
between, significantly affecting the resultant forces measured on
the dummy's head. (2) Permissible variations in the test procedure
for determining thorax dynamic spring rate (force deflection
characteristics on the dummy's chest) permit considerable latitude
in chest construction which could produce wide variations in maximum
chest deceleration between two different dummies, each of which
meets the literal requirements of SAE J963. (3) The absence of
specific, objective specifications for construction of the dummy's
head permits significant variation in forces imparted to the
accelerometer by which performance is to be measured.
    Id. at 676-78.
    \274\ Id. at 677.
    \275\ Id. at 677-79.
---------------------------------------------------------------------------

    Other courts have also reached similar conclusions. The Ninth
Circuit Court of Appeals, relying on the same reasoning adopted by the
Sixth Circuit, found that a compliance road test specifying the use of
surfaces specifically rated with quantifiable numbers (defining the
``slickness'' of the surfaces) was objective despite ``[t]he fact that
it is difficult to create and thereafter maintain a road surface with a
particular coefficient of friction,'' which the court held ``does not
render the specified coefficient any less objective.'' \276\ In this
case, both NHTSA and the manufacturer would perform road tests on
surfaces with identically rated friction coefficients.\277\ In a later
case, the Sixth Circuit upheld NHTSA's decision not to incorporate a
test suggested by a commenter for wheelchair crashworthiness performed
with a ``test seat'' that ``shall be capable of resisting significant
deformation'' during a test as not sufficiently objective.\278\ In the
absence of language quantifying how much deformation is significant,
terms such as ``significant deformation'' do not provide enough
specificity to remove the subjective element from the compliance
determination process.
---------------------------------------------------------------------------

    \276\ Paccar, Inc. v. Nat'l Highway Traffic Safety Admin., 573
F.2d 632, 644 (9th Cir. 1978), cert. denied, 439 U.S. 862 (1978).
    \277\ Id. (stating that the ``skid number method of testing
braking capacity meets the [objectivity] definition. Identical
results will ensue when test conditions are exactly duplicated. The
procedure is rational and decisively demonstrable. Compliance is
based on objective measures of stopping distances rather than on the
subjective opinions of human beings.'').
    \278\ Simms v. Nat'l Highway Traffic Safety Admin., 45 F.3d 999,
1007-08 (6th Cir. 1995).
---------------------------------------------------------------------------

    As discussed above, under the proposal, we have developed and are
proposing performance requirements, including compliance test
procedures, for DSRC. We will continue evaluating the compliance test
procedures further and receiving public input during the comment period
that can assist us in fine-tuning the procedures and ensuring that they
meet our statutory requirements. For alternative technologies, given
that the testing to this point that led to the development of the test
procedures for interoperability did not evaluate the use of non-DSRC
communication technologies, we seek comment on how the regulatory text
alternative technologies can achieve interoperability in an objective
manner.
4. ``Practicable'' Standards
    In general, the practicability of a given standard involves a
number of considerations. The majority of issues concerning the
practicability of a standard arise out of whether the standard is
technologically and economically feasible. An additional issue is
whether the means used to comply with a standard will be accepted and
correctly used by the public.
    First, significant technical uncertainties in meeting a standard
might lead a court to find that a standard is not practicable. For
example, the Sixth Circuit Court of Appeals upheld NHTSA's decision to
amend FMVSS No. 222 to include requirements for wheelchair securement
and occupant restraint on school buses with a static \279\ compliance
test instead of a dynamic test,\280\ noting that the administrative
record showed that this particular dynamic test was underdeveloped and
had many unresolved technical problems.\281\ The court noted that it is
not practicable ``[t]o attempt to fashion rules in an area in which
many technical problems have been identified and no consensus exists
for their resolution . . . .'' \282\ In another example, the Ninth
Circuit Court of Appeals found a compliance test procedure using a
specified friction (slickness) coefficient to be impracticable due to
technical difficulties in maintaining the specific slickness test
condition. As mentioned

above, the Ninth Circuit found the specified coefficient test condition
to be objective.\283\ However, simply being objective did not also make
the test condition practicable. Thus, the cases show that when
significant technical uncertainties and difficulties exist in a
standard promulgated by NHTSA, those portions of the standard can be
considered impracticable under the Safety Act.
---------------------------------------------------------------------------

    \279\ Static testing tests the strength of individual components
of the wheelchair separately, while dynamic testing subjects the
entire wheelchair to simulated real-world crash conditions. See
Simms, 45 F.3d at 1001.
    \280\ Id. at 1006-08. Petitioners argued that NHTSA had acted
unlawfully in promulgating standards for the securement of
wheelchairs on school buses based only on ``static'' instead of
``dynamic'' testing. Id. Static testing tests the strength of the
individual components of a securement device. Id. Dynamic testing is
a full systems approach that measures the forces experienced by a
human surrogate (test dummy) in a simulated crash that replicates
real-world conditions and assesses the combined performance of the
vehicle and the securement device. Id.
    \281\ Id. at 1005-07. NHTSA agreed that dynamic testing is the
preferred approach (because it more fully and accurately represents
the real-world conditions in which the desired safety performance is
to be provided), but explained that it was not practicable at that
time to adopt dynamic testing because there was:
    (1) [N]eed to develop an appropriate test dummy; (2) need to
identify human tolerance levels for a handicapped child; (3) need to
establish test conditions; (4) need to select a ``standard'' or
surrogate wheelchair; (5) need to establish procedures for placing
the wheelchair and test dummy in an effective test condition; and
(6) need to develop an appropriate test buck to represent a portion
of the school bus body for securement and anchorages.
    Id. at 1005.
    \282\ Id. at 1010-11.
    \283\ Paccar, Inc. v. Nat'l Highway Traffic Safety Admin., 573
F.2d 632, 644 (9th Cir. 1978).
---------------------------------------------------------------------------

    However, the requirement that a standard be technologically
feasible does not include the additional requirement that the agency
show that the technology to be used to comply with the standard is
already fully developed and tested at the time that the standard is
promulgated. The Sixth Circuit upheld a NHTSA standard requiring
``Complete Passive Protection,'' that required the installation of
airbags as standard equipment by a future date, rejecting petitioner's
contention that NHTSA may only establish performance requirements which
can be met with devices which, at the time of the rulemaking, are
developed to the point that they may be readily installed.\284\ Relying
on the legislative history of the Safety Act, the court found that the
agency ``is empowered to issue safety standards which require
improvements in existing technology or which require the development of
new technology, and is not limited to issuing standards based fully on