Support version 1 cert generation

[Michael StJohns]

Hi -

To be very specific here - if a certificate has extensions, it MUST be 
version 3, otherwise it SHOULD be version 1, but may be version 2 or 3.  
(If a certificate has either of the issuer or subject unique ID fields, 
it must be at least version 2 - but those fields are deprecated as a 
MUST NOT for conforming CAs, so you should never issue a certificate 
with those fields).

A CA certificate (i.e. an intermediate certificate) is required to have 
a basicConstraints extension - and must be a version three certificate.

If you do this (support V1 cert gen), I'd make it a side effect of 
whether or not you add extensions instead of a discrete option.

Later, Mike


On 5/17/2016 7:45 AM, Sean Mullan wrote:
> Hi Xuelei,
>
> Can you elaborate under what circumstances this is useful for testing? 
> X.509 v3 was first published in 1996, and v1 certificates should be 
> pretty much non-existent these days (although there are some root 
> certs that are still v1). v1 certificates do not support extensions. 
> Adding support may cause users to (accidentally) start using them in 
> practice, which would not be good. PKIX (RFC 3280) states that 
> "Conforming implementations may choose to reject all version 1 and 
> version 2 intermediate certificates." (RFC 5280, section 6.1.4 step k).
>
> Thanks,
> Sean
>
> On 05/17/2016 12:44 AM, Wang Weijun wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8157109 filed.
>>
>> --Max
>>
>>> On May 17, 2016, at 12:25 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Keytool used to generate version 1 self-signed certificates. Now it is
>>> mandatory to be version 3.  Default version 3 should be OK. However, in
>>> some circumstances (for example for testing purpose), version 1
>>> self-signed certificate may still be useful.
>>>
>>> It would be a low priority, but may be nice to add an option to support
>>> specified certificate version number for certificate generation.
>>>
>>> Thanks,
>>> Xuelei
>>