At 11:36 AM -0800 12/28/97, Eric Rescorla wrote:
1. While overloading the cipherSuites mechanism is convenient and
backwards compatible, it strikes me as ill-advised. In the limit,
we end up with a large number of cipherSuites that differ only
in the types of certificational material they provide. This
fragments effort.
I agree, certificate type negotiation is an unfortunate missing piece from
TLS. However, according to Section 7.4.2 of the TLS spec and previous
discussion on the TLS list, overloading ciphersuites appears to be the
recommended way to introduce a new certificate type. Fortunately, the
ciphersuite field is 16 bits, so it doesn't seem that any valuable space is
being wasted.
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.
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.
Algorithm choice is largely orthogonal to certificate format and
should be represented as such. That does seem to be a missing
capability in TLS. We should add it rather than hacking around
it.
Bravo.
2. The Certificate payload design doesn't seem to allow for
a chain of certificates to be carried. This seems like a bug.
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.
These are both issues of certification of the received key. The OpenPGP
trust model works differently than the win or lose X.509 model where it is
essentially assumed that all clients have all root CA certificates and
those certificates are implicitly trusted. In the OpenPGP model, there is
generally no chain and if there is it could be multiple chains. In
practice, I suspect most implementations will in fact possess OpenPGP CA
keys and it will work much the same way. In this model however, a
certificate chain isn't used. 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. One
motivation in the document is also to reduce the overhead of the key
exchange. A key need not even be sent by sending the key ID instead. On
the first connection, this may incur some overhead if the the key is not
found because the certserver may need to be accessed. On future
connections (even when the sessions are not cached), this will be a
substantial benefit.
This method also introduces to TLS some of the flexibility afforded by SSH
where first connections could be assumed valid and future connections must
use the same keys. Again, this is an implementation dependent issue.
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.
5. Also, you've failed to call out support for the integrity only
cipherSuites. Is this intentional?
Not intentional. That is an oversight.
Thanks.
-Will
Will Price, Architect
Network Associates, Inc.
Direct (650)596-1956
Main (650)572-0430
Fax (650)631-1033
Cell/VM (650)533-0399
<pgpfone://clotho.pgp.com>
PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C>