Will Price wrote:
The alternative seems to be to include another subpacket in the Hello
packets negotiating certificate type just like compression is negotiated.
This would also be allowed by the spec as per 7.4.1.2. If it was to be
done that way, I felt that this negotiation should have been included in
the TLS spec. Since I assume the time for that has passed, I opted for
the ciphersuite overload.
I don't think it can go into TLS 1.0, but it's definitely something we
should work towards for a TLS 1.1 or 2.0.
Here you call out an RSA/3DES/RIPEMD mode. If that's a good idea,
wouldn't it be a good idea with X.509 certificates as well?
Yes, it would. Unfortunately once again, I assume the time to add such
things has passed. I felt it was important to have more than one hash
algorithm associated with the OpenPGP certificates, but didn't want to
use a potentially weak algorithm like MD5 (except where the TLS protocol
requires MD5). Were the TLS spec to ignore compatibility, I'm sure MD5
would be eliminated, so I didn't want to add it to any new ciphersuites.
RIPEMD-160 seemed an ideal replacement that was already part of OpenPGP.
HMAC-MD5 still appears to be strong. While it would be nice to eliminate
MD5 from TLS at some point, there don't seem to be a lot of good
alternatives. In my opinion, RIPEMD-160 hasn't seen enough analysis to
feel comfortable about it. I'd prefer to give it another few years, at
least.
3. Omitting the DistinguishedName field in the CertificateRequest
field seems problematic. I understand PGP doesn't use DNs,
but there should be a way to indicate who might be potential signers
of a given key.
OpenPGP keys generally have all the certs they need attached to them
whereas X509 certs are only a single cert unto themselves thus requiring
a chain if the specified cert is not directly certified by a root CA.
With OpenPGP, if a particular signer key is not found, the client or
server can use a certserver to look it up.
Although TLS uses the X.509 cert formats, it doesn't require an X.500
directory to operate. I don't think it's a good idea to require an OpenPGP
cert server, either.
4. In addition, I don't see what the point of prohibiting
"Export" ciphers with PGP keys is. Obviously, if you're explicitly
calling out cipherSuites, you can simply omit all the export cipher
suites from that list, but frankly, stating that "Export" algorithms
also may not be used with OpenPGP keys" seems silly. It's not our
place as protocol designers to tell people what they may use.
The export sections of TLS seem to me to be a holdover from the SSL
legacy days and are there mostly for compatability. OpenPGP pays no
attention to this issue as it isn't appropriate to have such limits in an
international standard. Clearly, an implementation could choose to
implement their own ciphersuites for export algorithms with OpenPGP keys,
but there doesn't seem to be any reason to specify those as none of the
export quality algorithms are supported by OpenPGP. Simply removing the
statement does seem appropriate however making them implicitly excluded
rather than explicitly.
While I support the ideal of building standards that use strong crypto, it
does nobody any good to create a standard which won't get implemented. The
export ciphers exist because in order for US software manufacturers to use
TLS, they have to be able to export the software that includes it. It is
certainly true that there are many software developers who live in the
free world, but those of us stuck in the US still need to sell software.
--
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice. You must understand Tao before |
tomw(_at_)netscape(_dot_)com
transcending structure. -- The Tao of Programming |