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