Platform Configuration Registers Open Config Standard based proto definitions for External Vendors#11
Conversation
…o Definitions for External Vendors
…initions for External Vendors
mihirpitale-googler
left a comment
mihirpitale-googler
left a comment
There was a problem hiding this comment.
adding bootloaderversion repeated pcr values and creating struct
mihirpitale-googler
left a comment
mihirpitale-googler
left a comment
There was a problem hiding this comment.
adding comments above attributes
| // http://www.apache.org/licenses/LICENSE-2.0 | ||
| // | ||
| // Unless required by applicable law or agreed to in writing, software | ||
| // distributed under the License is distributed on an "AS IS" B1IS, |
|
|
||
| package openconfig.pcrservice; | ||
|
|
||
| import "github.com/openconfig/attestz/proto/common_definitions.proto"; |
There was a problem hiding this comment.
thanks for pointing out.
|
|
||
| enum RootOfTrustVersion { | ||
| ROOT_OF_TRUST_VERSION_UNSPECIFIED = 0; | ||
| TPM_1.2_PCR = 1; |
| google.protobuf.Timestamp timestamp = 3; | ||
|
|
||
| // Date of PCR Artifact Collection | ||
| google.type.Date calendar_date = 4; |
There was a problem hiding this comment.
Why do we have the time twice - timestamp and calendar_date?
There was a problem hiding this comment.
sure, will remove calendar_date since its overlapping.
| service SecurityService { | ||
|
|
||
| // Retrieves the PCR values for a specific software/hardware/bootloader combination. | ||
| rpc GetPCR(GetRequest) returns (GetResponse); |
There was a problem hiding this comment.
nit: Lets change this RPC to FetchPCR and the messages to message PCRRequest and message PCRResponse
There was a problem hiding this comment.
sure, modified
| option go_package = "github.com/openconfig/pcrservice"; | ||
|
|
||
|
|
||
| // Enumerations |
There was a problem hiding this comment.
these need docstrings describing use
| TPM_2_0_PCR = 2; | ||
| } | ||
|
|
||
| enum BootStage { |
There was a problem hiding this comment.
And reference the table in TCG documentation from whence the initial list came?
There was a problem hiding this comment.
done updated
| } | ||
|
|
||
| // Request for fetching all known bootloader versions for a specific hardware model. | ||
| message FetchBootLoaderVersionsRequest { |
There was a problem hiding this comment.
shouldn't this have the software version as well?
There was a problem hiding this comment.
ack marcus, yes i believe we should add software version here as well
|
|
||
| // Response containing a list of known hardware model strings. | ||
| message FetchHardwareModelsResponse { | ||
| // List of valid hardware model strings (e.g., "A9K-400-LC", "Nokia-7750") |
There was a problem hiding this comment.
I think this description needs to be more specific. If not, every vendor will choose their own format and content.
Does the mfg belong in the model, like "Nokia-7750" and "Cisco-A9K-400-LC"? Do we want linecards to be included, like "A9K-400-LC"?
The same for software versions; what should the format be?
There was a problem hiding this comment.
ack john, updated docstrings
|
|
||
| // Response containing a list of known bootloader version strings. | ||
| message FetchBootLoaderVersionsResponse { | ||
| // List of valid bootloader version strings for the specified hardware model |
There was a problem hiding this comment.
Where is the software variant? That is also missing from FetchSoftwareVersionsResponse.
I feel as if I am reviewing an old version. Stuff that I was expecting to be present from our chat discussions are missing.
There was a problem hiding this comment.
Are we (with this PR) commiting half the work on purpose because someone else (betul?) has queued up a bunch of further enhancements?
that'd be fine I bet... 'get progress now so more progress sooner'
There was a problem hiding this comment.
maybe; if that is so, just commit it and go from there.
There was a problem hiding this comment.
yes chris/john. ill commit this pr for betul to add on further enhancements.
haussli
left a comment
haussli
left a comment
There was a problem hiding this comment.
We have decided to commit the current draft and continue development from there.
|
Mihir, do we need another review? I thought that this was going to merged, then the other suggestions, including those from Marcus would be merged/discussed. |
|
We have established a general logical set here: a downloaded image and derivative metadata, including supported OpenConfig xpaths, SBOM, and golden PCR values for that image. Importantly, image and metadata are only meaningful when paired tightly together. It is conceivable that additional metadata (PQC, supported OpenConfig global versions, etc.) will be added in the future. Instead of developing several disjoint protocols in piecemeal fashion, have we considered building a single comprehensive and extensible protocol which covers the downloaded image and all associated artifacts, emphasizing the tight coupling of the logical set? Because of shared nature, it is my recommendation that we combine these operations to reduce complexity and enhance intuitiveness instead of treating them as unrelated problems. Thanks. |
mihirpitale-googler
left a comment
mihirpitale-googler
left a comment
There was a problem hiding this comment.
resolved comments
11 participants
Description
The current lack of a unified standard for vendors to provide Platform Configuration Register (PCR) values—characterized by less secure delivery methods like Excel or JSON and disparate data formats—severely hampers the scalability and reliability of Google’s Attestation service for network infrastructure.
This fragmentation necessitates manual data entry and creates significant operational toil, ultimately slowing down the integrity verification process for network devices. To resolve this, we propose a standardized OpenConfig schema and protobuf-based framework that mandates vendors to deliver PCR values in a consistent, hex-standardized format via secure endpoints with every software release. By automating the ingestion of these measurements, the solution ensures a more reliable and efficient way to verify device trustworthiness across the network.