[
https://issues.apache.org/jira/browse/QPID-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130145#comment-18130145
]
ASF GitHub Bot commented on QPID-8773:
--------------------------------------
pmaripini-salesforce opened a new pull request, #465:
URL: https://github.com/apache/qpid-broker-j/pull/465
JIRA: https://issues.apache.org/jira/browse/QPID-8773
## Summary
This is the first, smaller part of #464, split out so that the SPI types can
be reviewed on their own. It adds the
`org.apache.qpid.server.security.certificate` package to broker-core. Nothing
uses it yet, so the broker's behaviour does not change and broker-core still
depends on Bouncy Castle.
#464 stays open as the complete change. Once this PR is merged, #464 will be
rebased onto it so that only the generator plugin and the broker wiring remain.
## Changes
- `CertificateGeneratorFactory extends Pluggable`: has a no-argument
constructor without side effects. `create()` returns a `CertificateGenerator`
and may throw `GeneralSecurityException`.
- `CertificateGenerator`: `GeneratedCertificate
generate(CertificateRequest)`. Its javadoc defines the certificate every
generator must produce:
- X.509 v3, DER encoded, and parseable by the JVM's `CertificateFactory`.
- Self-signed, using the request's subject and validity.
- A positive serial number of at most 20 octets.
- A critical basic constraints extension marking it as an end entity.
- A non-critical subject alternative name extension, added only when there
are names or addresses.
The javadoc also says which unchecked provider failures are reported as
`GeneralSecurityException`. Implementations must not register security
providers, and should use default JCA provider selection.
- `CertificateRequest`: immutable, and built with
`CertificateRequest.builder()`.
- The validity is truncated to whole seconds, the precision X.509 stores,
and the start must be before the end.
- The subject must not be empty, and the key length must be positive.
- DNS names that are not valid host names, such as textual IP addresses,
are left out (logged at debug), so every generator sees the same names.
- `GeneratedCertificate`: a record holding the private key and the
certificate. Its `toString()` leaves out the private key.
- `AbstractCertificateGeneratorContractTest`: the behaviour expected of
every generator, for implementations to extend. It covers RSA and EC keys and
requested key lengths, self-signing, validity (including dates after 2049),
basic constraints, subject alternative names (including scoped IPv6 addresses),
serial numbers, error reporting, and that the generator does not register
security providers. No implementation is part of this PR; the Bouncy Castle
generator in #464 runs it.
- Unit tests for `CertificateRequest` and `GeneratedCertificate`.
## Testing
`mvn -pl broker-core -am verify
-Dtest='CertificateRequestTest,GeneratedCertificateTest'` against `main`: 12
tests, all passing. The contract test passes for the Bouncy Castle generator in
#464.
> Decouple self-signed certificate generation from Bouncy Castle to support
> FIPS 140 deployments
> ----------------------------------------------------------------------------------------------
>
> Key: QPID-8773
> URL: https://issues.apache.org/jira/browse/QPID-8773
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Partha Sarathy Maripini
> Priority: Major
> Labels: FIPS, Security
>
> *Motivation:*
> Deploying Apache Qpid Broker-J in enterprise and regulated environments (such
> as govcloud) requires FIPS 140 compliance. Broker-J's only direct use of
> Bouncy Castle in the broker runtime is building the self-signed certificate.
> Because that code is in broker-core:
> 1. Every deployment carries the standard Bouncy Castle libraries
> (bcprov-jdk18on / bcpkix-jdk18on), which are not FIPS 140 certified;
> 2. The static BouncyCastleProvider in SSLUtil conflicts with a runtime that
> supplies its own Bouncy Castle libraries on the platform class loader.
> *Proposed Solution:*
> 1. Move self-signed certificate generation behind a small SPI in broker-core
> (CertificateGeneratorFactory / CertificateGenerator, discovered with
> QpidServiceLoader). broker-core then has no Bouncy Castle dependency, and an
> enforcer rule keeps it that way.
> 2. Move the existing Bouncy Castle code into a new plugin,
> qpid-broker-plugins-certificate-generator-bouncycastle, which the standard
> distribution includes. The plugin does not create or register a security
> provider: keys, signatures and certificate parsing use default JCA provider
> selection, so a FIPS provider preferred by the platform is used automatically.
> 3. Select the generator when the Broker starts. If one generator is installed
> it is used; if several are installed, the system property
> qpid.security.certificateGenerator selects one. An unknown type, or a
> generator that cannot be created, makes startup fail.
> 4. Deployments that must not use Bouncy Castle can leave the plugin out
> (keystores whose certificate is already stored still load) or install a
> different generator through the same SPI.
> *Impact:*
> No change for the standard distribution. Applications that embed
> qpid-broker-core directly must add the plugin and the Bouncy Castle libraries
> (bcprov, bcpkix, bcutil) to keep creating AutoGeneratedSelfSigned keystores.
> *Out of scope:*
> Other FIPS-related areas, such as BCFKS / PKCS12-PBMAC1 keystores or TLS
> through BCJSSE, can follow as separate issues if needed.
> *Note:* I am actively working on this change and will submit a Pull Request
> shortly.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
