Will Price <wprice(_at_)pgp(_dot_)com> writes:
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.
Hmm.. What it says is:
All certificate profiles, key and cryptographic formats are defined
by the IETF PKIX working group [PKIX]. When a key usage extension is
present, the digitalSignature bit must be set for the key to be
eligible for signing, as described above, and the keyEncipherment
bit must be present to allow encryption, as described above. The
keyAgreement bit must be set on Diffie-Hellman certificates.
As CipherSuites which specify new key exchange methods are specified
for the TLS Protocol, they will imply certificate format and the
required encoded keying information.
So, reading this literally, since OpenPGP isn't a PKIX work item,
what you suggest is impermissible. (I don't really suggest reading
this literally. I'm merely trying to make the point that TLS doesn't
appear to have any provision whatsoever for new certificate
formats, except what is required for new algorithms.)
Fortunately, the
ciphersuite field is 16 bits, so it doesn't seem that any valuable space is
being wasted.
Space isn't the issue, really. It's protocol maintainance and
reuse that's at issue. Nevertheless, I'd be wary of assuming that
we have an infinitude of cipherSuite space. We only do if we
don't waste it.
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'd suggest this as a TLS 2.0 wor k item, myself.
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 is not known to be weak. And remarkably little is known
about RIPEMD-160. I'm not really that confident it's better than
MD5.
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.
Let's take these two separately:
2. I'm pretty familiar with the OpenPGP certification model. What
I'm not that famaliar with is the OpenPGP certificate format.
The purpose of the exercise here is for the public keyholder
to provice enough certificates to enable the public key user to
verify his certificate. If PGP keys can have enough certificates
attached to them to provide this, then we don't have a problem.
A quick glance at the OpenPGP spec didn't make this clear, however.
In any case, this isn't an implementation issue if we don't provide
the facilities to make it possible.
As for cert servers, TLS with X.509 works perfectly well without
The Directory. (good thing too, since The Directory doesn't exist).
TLS with OpenPGP certificates should work equally well.
3. You haven't addressed the DN in certificate request issue. I
don't see that the OpenPGP cert structure has much relevance
here. Am I missing something.
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.
I completely disagree. The fact of the matter is that people who
ship TLS products often have to export them. In order to do so,
they need to use exportable ciphers. That's why SSL had them and
it's why TLS has them.
OpenPGP pays no attention to
this issue as it isn't appropriate to have such limits in an international
standard.
They aren't limits. They're options.
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.
You're failing to distinguish here between OpenPGP the messaging
format and OpenPGP the certification system. What you're trying to
do here is use OpenPGP certification with TLS protocol. What
crypto algorithms OpenPGP messaging supports really doesn't have
any relevance to this.
Simply removing the statement does
seem appropriate however making them implicitly excluded rather than
explicitly.
Right. The correct behavior is to specify them.
5. Also, you've failed to call out support for the integrity only
cipherSuites. Is this intentional?
Not intentional. That is an oversight.
I'd observe that this is the precise problem with having the certification
structure bound up in the cipherSuite. Keeping X.509 cipherSuites matched
with OpenPGP cipherSuites is going to be quite difficult.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."