Thierry Moreau wrote:
In draft-ietf-sip-dtls-srtp-framework, the detailed scheme uses
self-signed certificates created by client end-entities themselves.
The basic idea is identical. At the detailed level in my document, the
client end-entity "auto-issues" a security certificate with a
"breached" CA private key.
In the TLS Certificate request message, a list of CA distinguished
names is provided to the end entity. Referring to a "breached" CA
public key is an invitation to submit a meaningless end-entity
certificate, making the detailed scheme "more plain" with respect to
TLS options (i.e. an empty list in a certificate request message could
be a not so well supported mode in TLS software implementations).
So, maybe the reference to the notion of self-signed EE certificates
in draft-ietf-sip-dtls-srtp-framework could be replaced by
"meaningless EE certificates" (or something else), which would include
both self-signed or auto-issued. In such a case, the RFC publication
for my document would become more pressing.
A related discussion occurred on the IETK PKIX mailing list in June
2008 under the subject "RFC 5280 Question".
re:
http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application
security model
http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application
security model
http://www.garlic.com/~lynn/2008k.html#51 The PKC-only application
security model
another approach that X9 financial standard organization took to attempt
the enormous
digital certificate bloat was standards effort for "compressed" digital
signature ...
possibly reducing 100-times bloat to possibly only 5 to 10 times bloat.
There
was some conjecture that such "lightweight" digital certificates might
also find
place in wireless applications.
part of compression effort was to recognize that the server already had much
of the information was exactly the same in every certificate and/or the
server
already possessed.
I raised the issue (rather than harping on the theme that digital
certificates
being redundant and superfluous ... besides 100 times bloat) .... that
(for all the
situations they were looking at) the server already had all the
information in a digital
certificate. Therefor, it would be possible to define a new class of
zero byte
digital certificates that would be appended to every digitally signed
transaction.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
