feat: rsa handler#859
Conversation
…configurations (open-component-model#864) #### What this PR does / why we need it - Added a new Go module in `bindings/go/rsa/signing/v1alpha1` to support RSA signing configurations. - Implemented configurations for both `RSASSA-PSS` (probabilistic) and `RSASSA-PKCS1 v1.5` (deterministic) signature schemes. - Introduced support for signature encoding policies (`Plain` and `PEM`) to manage signature serialization and storage. - Added logic for media types, algorithms, and integration with runtime schemas. - Autogenerated necessary deepcopy and runtime type management code for reusability. #### Which issue(s) this PR fixes - Lays groundwork for integrating modern cryptographic signing methods. - Ensures backward compatibility with legacy PKCS1 v1.5 while promoting secure PSS usage. Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
7a6afa2 to
99e332c
Compare
…for RSA signing handlers (open-component-model#865) #### What this PR does / why we need it - Consolidated `PSSConfig` and `PKCS1V15Config` into a single `Config` abstraction to simplify configuration handling for RSA signing. - Added a new dynamic `Scheme` for consistent runtime type registration. - Developed an extensive RSA handler test suite: - Covers both `RSASSA-PSS` and `RSASSA-PKCS1 v1.5` signature algorithms. - Includes tests for various signature encoding policies (`Plain` and `PEM`). - Added error path tests for unsupported algorithms, missing credentials, and tampered signatures. - Enhanced identity handling for signing and verification configurations. #### Which issue(s) this PR fixes - Streamlines the configuration structure for RSA signing handlers. - Ensures better test coverage and resilience for edge cases and error scenarios. Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
99e332c to
d552844
Compare
matthiasbruns
left a comment
There was a problem hiding this comment.
More review tomorrow
Skarlso
left a comment
There was a problem hiding this comment.
Couple of first pass comments.
…er and matcher #### What this PR does / why we need it - Replaced the internal `dn` package with a new `rfc2253` package to handle Distinguished Names (DNs) in compliance with RFC 2253. - Improved parsing of escaped characters, quoted values, and encoded forms like `#hex`. - Added robust test coverage for conformance, equality, and matching rules. - Updated RSA signing handler to use the new `rfc2253` package for issuer verification. - Eliminated old `dn` parsing and matching logic, simplifying the handling code. - Enhanced error messages for DN matching failures for better clarity. - Introduced options for lenient or strict DN parsing modes. #### Which issue(s) this PR fixes - Aligns DN parsing and matching with RFC 2253 specifications. - Simplifies codebase by removing redundant and inconsistent logic. - Improves resilience and correctness in X.509 issuer verification so we are actually using a proper parsing specification instead of a best effort parser like with ocm v1 Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
#### What this commit does - Updated the `New` function's comment in `bindings/go/rsa/signing/handler/handler.go` to clarify the behavior when `useSystemRoots` is `false`. - Explicitly states that an empty certificate pool is used in such cases. #### Why this is needed - Ensures the behavior of the function is well-documented for developers, improving code readability and reducing potential confusion. Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
|
Well this comment here turned out to be a complete disaster. In OCMv1 we use a badly implemented, kind of weird parser infrastructure for issuer matching that is not really conforming to anything. Its a mix of OpenSSL and LDAP issuer String interpretation. To standardize here going forward I have decided after discussion with @Skarlso to implement a RFC2253 compliant distinguished name parser. This parser is important because previously in OCM we couldn't deal with a lot of common encoding formats for certificate attributes such as a simple Before you ask: Yes there are libraries available:
I did test this version here significantly but if we say its too bad to maintain, I suggest we take over https://github.com/tsaarni/x500dn/blob/master/dn.go and adjust it as per MIT license allowed for our requirements. Still a lot of code though... We decided to mark the entire PEM flow as experimental and proceed with our version of RFC2253 as we believe it to be the most accurate yet least used flow. |
…mental #### What this commit does - Changed the default signature encoding policy to `Plain` (`SignatureEncodingPolicyDefault`). - Marked `PEM` signature encoding as experimental with warnings during signing and verification. - Adjusted `handler.go` to use `context.Context` for logging warnings and improved code maintainability. #### Why this is needed - Aligns with simpler and more widely usable default (`Plain`) while leaving `PEM` as an experimental feature for selective use. - Improves clarity for developers by explicitly marking experimental features and providing logging to reduce confusion. Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
Skarlso
left a comment
There was a problem hiding this comment.
Largely okay. I could re-read this many times and perhaps find something. But we're going to have to iterate on them.
#### What this commit does - Updated `Equal` function in `rfc2253` package to return errors instead of a boolean. - Allows better debugging and tracing of mismatches in Distinguished Names (DNs). - Modified `handler.go` to handle errors returned by `Equal` and propagate detailed mismatch information. #### Why this is needed - Enhances error reporting for DN comparison issues, improving debugging and user feedback. - Aligns with the goal of providing robust and clear validation mechanisms for X.509 issuer verification logic. Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
e04c8a9 to
1b1c914
Compare
Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
…arity #### What this commit does - Simplifies the `ParseRSAPublicKeyPEM` function to return a single parsed `RSAPublicKeyPEM` when possible. - Updates documentation to better describe supported PEM containers (`PKCS#1` and `PKIX`) and return behavior. - Ensures function exits early if no PEM blocks are found, optimizing for clarity and correctness. #### Why this is needed - Reduces ambiguity in function usage by clarifying its behavior and supported formats. - Aligns with clean code principles by improving readability and maintainability. Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
- Updated `ParseRSAPublicKeyPEM` documentation to include support for X.509 certificates. - Improves clarity on accepted PEM container formats (`PKCS#1`, `PKIX`, and `X.509`). - Enhances developer understanding of the function's capabilities and use cases. Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it - Added a new Go module in `bindings/go/rsa` to support RSA signing configurations. - Implemented configurations for both `RSASSA-PSS` (probabilistic) and `RSASSA-PKCS1 v1.5` (deterministic) signature schemes. - Introduced support for signature encoding policies (`Plain` and `PEM`) to manage signature serialization and storage with both supported formats from OCMv1 - Added logic for media types, algorithms, and integration with runtime schemas. - Autogenerated necessary deepcopy and runtime type management code for reusability. - Wrote an extensive test suite for all possible signing/verification combinations available #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> part of open-component-model/ocm-project#648 --------- Signed-off-by: Jakob Möller <jakob.moeller@sap.com> Co-authored-by: Gergely Brautigam <gergely.brautigam@sap.com>
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it - Added a new Go module in `bindings/go/rsa` to support RSA signing configurations. - Implemented configurations for both `RSASSA-PSS` (probabilistic) and `RSASSA-PKCS1 v1.5` (deterministic) signature schemes. - Introduced support for signature encoding policies (`Plain` and `PEM`) to manage signature serialization and storage with both supported formats from OCMv1 - Added logic for media types, algorithms, and integration with runtime schemas. - Autogenerated necessary deepcopy and runtime type management code for reusability. - Wrote an extensive test suite for all possible signing/verification combinations available #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> part of open-component-model/ocm-project#648 --------- Signed-off-by: Jakob Möller <jakob.moeller@sap.com> Co-authored-by: Gergely Brautigam <gergely.brautigam@sap.com>
#### What this does - Added a new `SigningRegistry` to manage signing handler plugins. - Integrated signing handler support into the plugin manager and registries. - Updated dependencies in `go.mod` and `go.sum` to include the signing library. - Adjusted test cases to align with the new signing plugin functionality. _Note: I have made it so that Signing and Verification expect the same Config Type right now. Technically this is a bit of a conflict with the SigStore ADR Proposal because it would have two different configs for signing and verifications but I think having one type that can be used with different fields would also work, and its significantly easier to implement here_ #### Why this change is needed - Expands the plugin framework capabilities to include signing handlers for enhanced security and verification processes. part of adopting the RSA handler implemented for open-component-model/ocm-project#648 in #859. It would be registered as an internal handler via `RegisterInternalComponentSignatureHandler` in the CLI --------- Signed-off-by: Jakob Möller <jakob.moeller@sap.com>

What this PR does / why we need it
bindings/go/rsato support RSA signing configurations.RSASSA-PSS(probabilistic) andRSASSA-PKCS1 v1.5(deterministic) signature schemes.PlainandPEM) to manage signature serialization and storage with both supported formats from OCMv1Which issue(s) this PR fixes
part of open-component-model/ocm-project#648