Sean,
I didn't check that anything else changed, but textually looks good.
One comment: you should consider including a link to RFC 5746 like we
do for all of the other RFCs.
If you have time, can you also add the link to the RFC where the
TLS_EMPTY_RENEGOTIATION_INFO_SCSV is defined?
And
I have posted the 3rd revision of the required algorithms list at:
http://cr.openjdk.java.net/~mullan/5001004/review.02/StandardNames.html#impl
Changes since the initial (00) version are:
- added MD5 and HmacMD5 to the required algorithms
- added the CertPath Encodings PKCS7 and PkiPath to the
On 12/20/10 7:29 AM, Florian Weimer wrote:
* Sean Mullan:
Oh, and I just realized that MD5 and HmacMD5 are missing. These
algorithms are still heavily used (and HmacMD5 is not really broken,
it's only guilty by association).
Yes, MD5 is still in use, but I think it is decreasing in use
signi
* Sean Mullan:
>> Oh, and I just realized that MD5 and HmacMD5 are missing. These
>> algorithms are still heavily used (and HmacMD5 is not really broken,
>> it's only guilty by association).
>
> Yes, MD5 is still in use, but I think it is decreasing in use
> significantly. Can you give more ratio
>From my understanding, MD2 and MD5 is unsafe because one can forge one
thing (such as, a certificate) with different content, but the same
signature. If we continue support verification based on MD2 and MD5, it
also means that the attack with the forged certification works. We may
not be able to p
Is it possible to deprecate the signing part of the mechanism while requiring
the verification part?
There's a whole pile of MD5withRSA and MD2withRSA root certificates.
Obviously, you don't want to support further signatures, but it would be useful
if you can still verify.
Or too much work?
On 12/16/10 1:26 PM, Sean Mullan wrote:
On 12/15/10 10:38 AM, Florian Weimer wrote:
Oh, and I just realized that MD5 and HmacMD5 are missing. These
algorithms are still heavily used (and HmacMD5 is not really broken,
it's only guilty by association).
Yes, MD5 is still in use, but I think it is
Ah yes there is that issue of course. I fully understand the reasoning
behind that. Too bad so many out there don't consider patent encumbering
when designing systems (such as ePassport as an example).
Cheers,
Tomas
On 12/16/2010 08:05 PM, Sean Mullan wrote:
> Right, but there are ECC patents th
On 12/17/2010 12:07 PM, Brad Wetmore wrote:
>> Brad, can you comment on the RFC 5746 support? Do you think we should
>> make the TLS_EMPTY_RENEGOTIATION_INFO_SCSV CipherSuite a requirement of
>> all Java 7 TLS 1.0 implementations?
>
> That's an excellent question. The RFC has been out less than a
I think the TLSv1 cipher suite list is effectively much longer.
Correct?
Yes, but only TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is mandatory. See
section 9 of RFC 2246: http://www.ietf.org/rfc/rfc2246.txt
I think it's prudent to require TLS_RSA_WITH_AES_128_CBC_SHA as well
(which is mandatory per R
Hi Florian,
SecureRandom is still underspecified. Most applications want an
algorithm which cannot block and will not wait for true, physical
randomness to arrive. If such applications accidentally use a
blocking generator (such as /dev/random on Linux without special
hardware support), then t
On 16 December 2010 19:05, Sean Mullan wrote:
> Right, but there are ECC patents that each vendor needs to consider on their
> own. Since these are requirements that all Java SE 7 implementations would
> have to support, it did not seem appropriate to make any ECC algorithms
> required or in gener
Right, but there are ECC patents that each vendor needs to consider on
their own. Since these are requirements that all Java SE 7
implementations would have to support, it did not seem appropriate to
make any ECC algorithms required or in general any algorithm that may be
protected by patents.
I don't see any ECC algorithms. These are in wide use today to say the
least. And will be so even more tomorrow (i.e. when Java SE 7 is out you
can not live without it).
Regards,
Tomas
On 12/15/2010 04:11 PM, Sean Mullan wrote:
Hello,
Currently, the Java security APIs do not specify algori
On 12/16/2010 11:30 AM, Florian Weimer wrote:
* Sean Mullan:
On 12/15/10 10:38 AM, Florian Weimer wrote:
* Sean Mullan:
Please review the following list:
http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
"SHA-1" or "SHA1"? (Our code uses "SHA1" for some reason,
* Sean Mullan:
> On 12/15/10 10:38 AM, Florian Weimer wrote:
>> * Sean Mullan:
>>
>>> Please review the following list:
>>> http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
>>
>> "SHA-1" or "SHA1"? (Our code uses "SHA1" for some reason, perhaps for
>> consistency with
On 12/15/10 10:38 AM, Florian Weimer wrote:
* Sean Mullan:
Please review the following list:
http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
"SHA-1" or "SHA1"? (Our code uses "SHA1" for some reason, perhaps for
consistency with "HmacSHA1".)
"SHA-1" is the stand
* Sean Mullan:
> Please review the following list:
> http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
"SHA-1" or "SHA1"? (Our code uses "SHA1" for some reason, perhaps for
consistency with "HmacSHA1".)
I think the TLSv1 cipher suite list is effectively much longer.
C
Hello,
Currently, the Java security APIs do not specify algorithm requirements for
implementations of Java SE. This makes it difficult to develop conformance
tests. Additionally, there is no guarantee that Java applications using these
algorithms can inter-operate. See bug 5001004 for more inf
19 matches
Mail list logo
