Skip to content

Conversation

@Sukuna0007Abhi
Copy link
Contributor

@Sukuna0007Abhi Sukuna0007Abhi commented Sep 23, 2025

Description:
This PR implements support for TPM vendor and model information in TPM endorsements, addressing Issue #139.

Changes include:

  • Extended TaAttr structure with vendor and model fields
  • Added input validation and sanitization for security
  • Implemented comprehensive test coverage:
    • Real-world TPM vendor/model combinations
    • International character handling
    • Security test cases
    • Edge cases and input validation
  • Updated documentation with new fields and security considerations

Security Considerations:

  • Implemented strict input validation
  • Added sanitization for potentially dangerous inputs
  • Protected against injection attacks
  • Enforced character and length limits

Testing:

  • Added extensive test suite covering:
    • Common TPM vendors (Infineon, STMicroelectronics, etc.)
    • International vendor names (Unicode support)
    • Security test cases (injection attempts)
    • Edge cases and combinations
    • Character type handling

Documentation:

  • Updated README.md with new field descriptions
  • Added security considerations
  • Included usage examples

Resolves: #139

Ready for Review sir @thomas-fossati @setrofim @yogeshbdeshpande

@Sukuna0007Abhi Sukuna0007Abhi changed the title Title: scheme/parsec-tpm: Add TPM vendor and model information Title: Scheme/parsec-tpm: Add TPM vendor and model information Sep 23, 2025
"key": [{
"type": "pkix-base64-key",
"value": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAETKRFE_RwSXooI8DdatPOYg_uiKm2XrtT_uEMEvqQZrwJHHcfw0c3WVzGoqL3Y_Q6xkHFfdUVqS2WWkPdKO03uw==",
"parameters": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe CoRIM crypto keys have additional parameters. Is this some extension or proposed change to the spec?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi sir @setrofim You're absolutely right to question this - CoRIM crypto keys in the standard specification do not have additional parameters.

This is indeed a Veraison-specific extension to the CoRIM spec. The standard IETF CoRIM specification defines crypto keys with only type and value fields.

I've implemented this extension because:

TPM-specific needs: TPM vendor/model information doesn't map naturally to the standard environment.class structure used by other schemes (like PSA)

Parsec profile: This follows the custom Parsec TPM profile ("tag:github.com/parallaxsecond,2023-03-03:tpm") which allows for scheme-specific extensions

Optional & backward compatible: Existing CoRIMs continue to work - this only adds optional metadata
I've updated the documentation to clearly indicate this is a Veraison extension and not part of the standard CoRIM specification. The implementation validates against our specific profile rather than claiming standard compliance.

Should I consider an alternative approach that stays closer to standard CoRIM, or is this extension acceptable for the parsec-tpm scheme's specific requirements? Pls reply

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

crypto-key-type-choice offers "type choice" rather than "map" extension point. Meaning you cannot add fields to existing values, you can only add new types. So you cannot add parameters to, e.g., "pkix-base64-key", you'd need to define a whole new type, "pkix-base64-key-with-params" and register that as an extension to the type choice (and then do the same for every other variant that needs to be extended in this way).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for guiding sir @setrofim, understood

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ready for review sir

@Sukuna0007Abhi Sukuna0007Abhi force-pushed the feature/tpm-vendor-model branch from 67d95ec to 7949f54 Compare October 4, 2025 13:05
@Sukuna0007Abhi
Copy link
Contributor Author

Ready for review sir @setrofim sir @yogeshbdeshpande sir @thomas-fossati

Copy link
Collaborator

@setrofim setrofim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

@yogeshbdeshpande yogeshbdeshpande left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check my comments!

@@ -0,0 +1,213 @@
// Copyright 2024 Contributors to the Veraison project.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering this generic implementation of string validation and checking for specific patterns is applicable more generically across entire Services scheme and could be moved to services/common ??

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this validation is particularly generic. For example, dangerousChars set does not include some punctuation that one may want to escape in other contexts (e.g. @, -, =, +, etc). Some checks (hasExcessiveRepitition, 'hasAbnormalDistribution`) use seemingly arbitrary thresholds. This all seems reasonable for Parsec/TPM (at least, for the prespective of someone not intimately familiar with the specs). However, if we want something generic, this is inadequate.

I'm not even sure we want generic santization -- different systems have different restriction on what they accept and what needs to be escaped (e.g. URL vs DB input vs environment/shell variables). It is better to do specific filtering/escaping at the point where it is relevant. Otherwise we just end up with iflters that are overly restrictive or result in excessive escaping.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, understood, thanks. Are these then coming from a spec reference for restriction in TPM specific scene setting?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I'm aware of (as I've said -- I'm not familiar with the specs). But this looks like it's designed specifically to catch "unreasonable" vendor/model names. From that point of view, the implementation looks reasonable. But I would not accept this as a good generic santizer (not do I think it's necesarily a good idea to have one).

@yogeshbdeshpande
Copy link
Collaborator

@Sukuna0007Abhi Let us discuss this PR in Veraison Meeting on 07/10/2025

@Sukuna0007Abhi
Copy link
Contributor Author

Sure sir, @yogeshbdeshpande will try my best, to explain properly 🙏

Comment on lines +41 to +44
Both fields support:
- Unicode characters (e.g., for international vendor names)
- Special characters (allowed in both fields)
- Variable length strings (no artificial length restrictions)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Both fields support:
- Unicode characters (e.g., for international vendor names)
- Special characters (allowed in both fields)
- Variable length strings (no artificial length restrictions)
Both fields support:
- Unicode characters (e.g., for international vendor names)
- Special characters (allowed in both fields)
- Variable length strings (no artificial length restrictions)


### CORIM Example

To include vendor and model information in your CORIM manifest, add them to the `environment.class` section (following standard CoRIM specification). Here are several examples:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To include vendor and model information in your CORIM manifest, add them to the `environment.class` section (following standard CoRIM specification). Here are several examples:
To include vendor and model information in your CoRIM manifest, add them to the `environment.class` section (following standard CoRIM specification). Here are several examples:

]
}
```

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think we need additional example, just drop them

Comment on lines 166 to 189
### Security Considerations

When using vendor and model fields:

1. **Input Validation**:
- Maximum length: 1024 characters
- Strings are trimmed of leading/trailing whitespace
- Basic sanitization is applied to prevent injection attacks
- Control characters are removed (except newline and tab)

2. **Storage**:
- Fields are optional and won't affect TPM validation
- Unicode characters are preserved for international vendor names
- Dangerous characters are escaped to prevent injection

3. **Best Practices**:
- Use consistent vendor/model identifiers
- Prefer official vendor names and model numbers
- Keep strings concise and meaningful
- Test with various character encodings if using international names

Note: The vendor and model fields are always optional and are meant for informational purposes only. The TPM's security validation is based solely on its cryptographic identity and measurements.
```
```
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not need any special Security Considerations for Vendor and Model, so please drop this section!

if env.Class.Vendor != nil {
vendor := string(*env.Class.Vendor)
// Trim and validate
vendor = sanitizeAndValidate(vendor)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line 131 not needed!

if env.Class.Model != nil {
model := string(*env.Class.Model)
// Trim and validate
model = sanitizeAndValidate(model)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line 139 not needed!

func (o *CorimExtractor) SetProfile(profile string) {
o.Profile = profile
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove Lines 213 to 231

@@ -0,0 +1,213 @@
// Copyright 2025 Contributors to the Veraison project.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

File can be deleted!

@@ -0,0 +1,125 @@
// Copyright 2025 Contributors to the Veraison project.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

File can be deleted!

Copy link
Collaborator

@yogeshbdeshpande yogeshbdeshpande left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my all comments, please re-work on the PR!

VerifKey *string `json:"parsec-tpm.ak-pub"`
ClassID *string `json:"parsec-tpm.class-id"`
InstID *string `json:"parsec-tpm.instance-id"`
// Optional vendor information for the TPM
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not just the Trust Anchor but the supply chain for SwAttr (line 24) which also has class, needs the Optional Vendor and Model information

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sukuna0007Abhi and others added 5 commits October 9, 2025 21:36
This change implements support for TPM vendor and model information in TPM
endorsements (Issue veraison#139). The implementation includes:

- Extended TaAttr structure with vendor and model fields
- Input validation and sanitization for security
- Comprehensive test coverage including:
  * Real-world TPM vendor/model combinations
  * International character handling
  * Security test cases
  * Edge cases and input validation
- Updated documentation with new fields and security considerations

Signed-off-by: Sukuna0007Abhi <[email protected]>
Following @setrofim's feedback that crypto-key-type-choice uses
'type choice' not 'map' extension point, refactored to comply with
standard CoRIM specification.

Changes:
- REMOVED: key.Parameters approach (invalid per CoRIM spec)
- ADDED: Extract vendor/model from environment.class (standard location)
- Follows same pattern as PSA scheme
- Fixed regex backreference issues in sanitization
- Updated README with complete, valid CoRIM examples
- Deleted ta_attrs.go and related test files (wrong approach)
- All tests passing

This addresses the review comment that we cannot add parameters
to existing key types like 'pkix-base64-key'. Instead, vendor/model
are now stored in the standard environment.class location.

Resolves: CoRIM specification compliance issue

Signed-off-by: Sukuna0007Abhi <[email protected]>
Signed-off-by: Sukuna0007Abhi <[email protected]>

Co-authored-by: Yogesh Deshpande <[email protected]>
Signed-off-by: Sukuna0007Abhi <[email protected]>
Signed-off-by: Sukuna0007Abhi <[email protected]>

Co-authored-by: Yogesh Deshpande <[email protected]>
Signed-off-by: Sukuna0007Abhi <[email protected]>
- Remove sanitization files (sanitize.go, sanitize_test.go)
- Extract vendor/model directly without validation
- Simplify README: keep one example, remove Security section
- Add vendor/model support to SwAttr for supply chain

Addresses feedback from sir @yogeshbdeshpande

Signed-off-by: Sukuna0007Abhi <[email protected]>
@Sukuna0007Abhi Sukuna0007Abhi force-pushed the feature/tpm-vendor-model branch from b3c6251 to 2b059c7 Compare October 9, 2025 21:37
@Sukuna0007Abhi
Copy link
Contributor Author

Ready for review sir @yogeshbdeshpande

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Parsec TPM endorsements - consider extending with vendor and model info

3 participants