Re: RFR: 8255739: x509Certificate returns � for invalid subjectAlternativeNames [v2]

[Michael StJohns]

On 1/24/2022 2:23 PM, Weijun Wang wrote:
> On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano <myano at openjdk.org> wrote:
>
>>> Could you please review the JDK-8255739 bug fix?
>>>
>>> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB.
>>>
>>> I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that.
>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    8255739: x509Certificate returns � for invalid subjectAlternativeNames
> Hi Mike, we don't support an OAEP key (i.e. RSA keys with OAEP parameters). If you want OAEP encryption, just use a plain RSA key and pass an OAEPParameterSpec to the RSA Cipher's init method.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/6928

Hi -

The RSA key just used a different AlgorithmIdentifier from the normal 
parameterless rsaEncryption AlgorithmIdentifier.   This issue basically: 
https://github.com/openssl/openssl/issues/7907. The TCG originally 
specified that the EK certificate contained the TPM's endorsement public 
key would be identified by the  that any endorsement key public key 
would be identified with the RSAES-OAEP  { pkcs-1 7 } object identifier 
instead of the rsaEncryption  {pkcs-1 1 } OID since the key was only 
supposed to be used for decrypting a credential encrypted under OAEP.  
e.g. the cert contained this sequence for the SubjectPublicKeyInfo:

>   SEQUENCE {
>  175   34:       SEQUENCE {
>  177    9:         OBJECT IDENTIFIER rsaOAEP (1 2 840 113549 1 1 7)
>  188   21:         SEQUENCE {
>  190   19:           [2] {
>  192   17:             SEQUENCE {
>  194    9:               OBJECT IDENTIFIER
>          :                 rsaOAEP-pSpecified (1 2 840 113549 1 1 9)
>  205    4:               OCTET STRING 'TCPA'
>          :               }
>          :             }
>          :           }
>          :         }
>  211  271:       BIT STRING, encapsulates {
>  216  266:         SEQUENCE {
>  220  257:           INTEGER
>          :             00 8A 80 D6 D1 A9 AD 54 92 A4 D2 AA F1 8A C8 D3
>          :             48 12 2E 17 E4 2C FC 75 CF 57 A3 E4 33 EC C8 FD
>          :             7D 2D 5E B4 13 F9 5D A9 45 51 E1 F1 22 F9 3C DA
>          :             39 69 AB 8D 85 72 74 D9 97 9C A2 6E D1 BE 9B 93
>          :             0A 83 1A 9D 2F 30 AA B1 F8 B8 89 04 34 1B 2C 72
>          :             31 BF 1F 67 44 79 B9 9E 35 A8 99 06 56 7B 92 28
>          :             C4 21 B9 90 7E C8 41 09 F5 88 C2 23 28 DE 25 CA
>          :             AF C2 2B 2E 61 DB 8B 17 83 BB 74 9A 4F A8 D4 A3
>          :                     [ Another 129 bytes skipped ]
>  481    3:           INTEGER 65537
>          :           }
>          :         }
>          :       }

Except for the weird AlgorithmIdentifier this is a bog standard RSA 
public key.

I don't know that its worth the time to fix this - it's already been 
deprecated by the TCG and I haven't seen an endorsement certificate with 
this particular encoding in a long while.  The certificate this key is 
from was issued 26 April 2012 and - for some strange reason - expires 
the same date this year.

Later, Mike