[security-dev 00576]: Re: Code review request: 6780416: New keytool commands/options: -gencert, -printcertreq, -ext

[Sean Mullan]

Max (Weijun) Wang wrote:
> 
> On Feb 18, 2009, at 6:17 PM, Xuelei Fan wrote:
> 
>> > If you find the webrev too long, you might only review a part of it.
>>
>> sun/security/x509/SubjectInfoAccessExtension.java:
>>
>> This class looks fine for me except that the SubjectInfoAccessSyntax 
>> is introduced from RFC3280, so I think it would be better change line 
>> 50 from RFC5280 to RFC3280.
> 
> It was introduced in a previous RFC, but I think if the definition is 
> not changed in a newer RFC, using the new RFC in the document is not a 
> bad thing.
> 
> This is the process I would choose regarding old and new spec:
> 
> If you're writing something new, always try to use the new spec, and 
> document it. For existing codes, if there's no enhancement in the new 
> spec, simply update the document link in the codes to point to the new 
> one. Otherwise, keep the old document link until the codes is updated to 
> reflect the new features, and then update the document link.
> 
> Does this sound rational?

I think we should try to be more consistent. I think it is confusing if some 
code/classes reference RFC 2459, others reference 3280 and others 5280 as the 
RFC should be treated as a whole. Towards the end of JDK 6 release, I changed 
all of the RFC 2459 references to RFC 3280 and made sure we passed all of the 
mandatory PKITS [1] tests. For JDK 7, we should be aiming to be compliant with 
RFC 5280. I have not done a careful analysis of that document to know if we need 
to make any changes or not. I am not sure if the PKITS test suite will be 
updated to RFC 5280.

My suggestion for now would be to leave the references as RFC 3280 and open a 
separate RFE for JDK 7 to check our APIs and implementation with respect to RFC 
5280, fix any issues, and then update the references.

--Sean

[1] http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html