The PKC-only application security model ...
Anne & Lynn Wheeler
lynn at garlic.com
Thu Jul 24 10:29:34 EDT 2008
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 majordomo at metzdowd.com
More information about the cryptography
mailing list