RFR: 8296736: Some PKCS9Attribute can be created but cannot be encoded

Xue-Lei Andrew Fan xuelei at openjdk.org
Thu Nov 10 02:05:31 UTC 2022


On Wed, 9 Nov 2022 21:54:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> One `PKCS9Attribute` can be created but cannot be encoded. Since the `SigningCertificateInfo::parse` method has not fully parsed the data (`PolicyInformation` is left out), this code change add the encoding itself as a field to the `SigningCertificateInfo` class so we can encode it.
> 
> After this change, unsupported `PKCSAttribute` object simply cannot be created. The `new(DerValue)` constructor rejects them (type 9-13, 15) in a `switch` block, and the `new(ObjectIdentifier, Object)` constructor rejects them because `VALUE_CLASSES` for them are null.
> 
> In the `encode()` method, we now throw `IllegalArgumentException` for these types and they will not happen.

Is it a real problem reported in productive environment?  I was just wondering if it is a feature that nobody used it yet.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 628:

> 626:             // break unnecessary
> 627: 
> 628:         case 16:    // SigningCertificate

I may prefer to use enum for PKCS9_OIDS so that we don't worry about if 16 is mapping to SigningCertificate while reading the code.  But it is not in the scope of this PR.

src/java.base/share/classes/sun/security/pkcs/SigningCertificateInfo.java line 92:

> 90:     }
> 91: 
> 92:     public byte[] toByteArray() {

Is it possible to have the method package private?

-------------

Changes requested by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11070



More information about the security-dev mailing list