-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIB9TCCAYcCEB5OR8gexDQvgZSTXDUUG5kwDQYJKoZIhvcNAQECBQAwaDELMAkG
A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
VQQLExNQZXJzb25hIENlcnRpZmljYXRlMRkwFwYDVQQDFBBqZWZmdEBuZXRjb20u
Y29tMB4XDTk0MDkxMzAyNDg0OFoXDTk2MDkxMjAyNDg0OFowaDELMAkGA1UEBhMC
VVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQ
ZXJzb25hIENlcnRpZmljYXRlMRkwFwYDVQQDFBBqZWZmdEBuZXRjb20uY29tMHAw
CgYEVQgBAQICArwDYgAwXwJYDXP4CqdnD0Q5AxAsHzfAkJYE4Ws2d0eUFFRjOztp
+beyPeGbFfMlE7wYT3TN3FYieTRSOSv5YmgEqZNANgzor64gpp10hzDlljRcMyn8
E5GXM/oXGSiR2QIDAQABMA0GCSqGSIb3DQEBAgUAA1kABAqLfqe7u9+JmkBZ3Ex/
phh4/B+5qoyAaMoTOm6cvn1hK76FbQo+SxOTkUC6KBkrrr5u76vwi/k5hF/J+epw
xvm6OLfZn7w23ldG6M39uHOuEOQGcVg9ug==
Issuer-Certificate:
MIIBwjCCAV4CAgHzMA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwHgYD
VQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBD
ZXJ0aWZpY2F0ZTAeFw05NDA5MTMwMjQ4NDhaFw05NjA5MTIwMjQ4NDhaMGgxCzAJ
BgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoG
A1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEZMBcGA1UEAxQQamVmZnRAbmV0Y29t
LmNvbTBwMAoGBFUIAQECAgK8A2IAMF8CWA1z+AqnZw9EOQMQLB83wJCWBOFrNndH
lBRUYzs7afm3sj3hmxXzJRO8GE90zdxWInk0Ujkr+WJoBKmTQDYM6K+uIKaddIcw
5ZY0XDMp/BORlzP6FxkokdkCAwEAATANBgkqhkiG9w0BAQIFAANPAAGN9s7SDw71
MLHuS/lwnxdsTvkyLalUxb2/0n3mQZKyIVemkjaecb7nLTHwXxR9RVnOqqnqMNFR
Rkla771LqUznOZmXhiuItNqErfNbag==
Issuer-Certificate:
MIIBxzCCAVECBQJAAAAUMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UECxMlTG93IEFz
c3VyYW5jZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NDAxMDcwMDAwMDBa
Fw05NjAxMDcyMzU5NTlaME0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0
YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTBp
MA0GCSqGSIb3DQEBAQUAA1gAMFUCTgaqCFANr1eL/bMB1gSolUhxiGUs3UWkj21d
DWbrNnf09hcrxSGiPQSzuRZG/yELTi+qQ4rCd1ZvNW2+gdA6Y/yc6SS4GL4BC+AW
hFyA5QIDAQABMA0GCSqGSIb3DQEBAgUAA2EAP/lSjvEN2nj2hmb0ag1w+FlxbV76
eiMu8ddYBT8IGTB9xH4VJ/iFDl4W7UCNi/pap/jfRd70S3n6OCcxOKrgufCBN0Dz
FBfh6UnP1DNChuQTddU6NUC0IVyaKKfzREHw
MIC-Info: RSA-MD5,RSA,
Co7tfv5ypIbiA9c4P5h8c4fbELg5KQhyLXCWkbNCpz7YgNr1CqyAthQnTvR+HDfx
0IQXu+A1D44hXrqmmnMq9lTd4JKrvrNuhE+KAJK9i7pL8c8oWtxOPw==
I'm glad to hear it. In case you didn't know, this is exactly the
approach taken by RIPEM 2.0 which we have now released. We use the
syntax from RFC 1421 and modify only one thing by introducing
Recipient-Key-Asymmetric which indicates the recipient of an ENCRPTED
message simply by the public key. (RFC 1421 indicates the recipient
by the issuer, which doesn't work in a direct trust environment with
no issuers. Besides, a recipient will always recognize and trust
their own public key without need of certification. This in fact works
fine with full-blown RFC 1422 hiererchies.)
- Jeff
Jeff, I 'm not sure who or what netcom is, or what exactly your role is, but
you
seem to be playing a significant role in the RIPEM development.
Netcom is just my Internet service provider. Indeed, I wrote the
certificate and CRL extensions for RIPEM 2.0 (previous version 1.2).
Can you estimate how many RIPEM users there are now?
I don't know the number. It is based on RSAREF and distributed under
accessed ftp at RSADSI and Michigan State University (Mark Riordan),
so maybe they have numbers. A signature-only version, RIPEM/SIG, has
a Commerce Jurisdiction to be exported freely, so there may be sites
all over the world.
I would be quite interested to know your thoughts on the degree to which the
modifications I have suggested to the PEM/MIME spec would dovetail with
RIPEM, and
what the possibilities are of enhancing the interoperability between the two
systems.
Would you outline the existing differences, and which ones you consider
relatively
major, either from a philosophy or an inpact-on-code and/or the existing user
base?
And finally, since RIPEM seems to be using bare keys (if I understand you
correctly?) as opposed to certificates, what kind of a system is used for
storing
the keys and/or binding them to users?
RIPEM does not use bare keys. It uses X.509 certificates. The only
difference from classic RFC 1421 is that it allows the
Originator-Certificate to hold a self-signed certificate, as opposed
to a certificate from a particular issuer. As in the header above,
certificates from particular issuers can be included as
Issuer-Certificates - from the Persona Certification Authority in
this case.
The bare key you mention is only for the recipient of an ENCRYPTED
message. I would reiterate: there is no need for the recipient to be
indicated by a Warwick-style key selector or issuer/serial because
the recipient already knows their own public key. When I receive an
ENCRYPTED message, there is no need for me to look up my own key in a
database, or to verify a certificate from an issuer. When I was
participating in RFC 1421 development, if I had thought of just
putting the public key in a Recipient-Key-Asymmetric, instead of
using the recipient's issuer/serial in a Recipient-ID-Asymmetric,
even for strict 1422 hierarchies, I would have mentioned it then and
I think it would have been accepted. Doing this has nothing to do
specifically with direct trust. I think the recipient ID just ended
up that way out of aesthetic symmetry with the Originator-ID which is
an issuer/serial. (At least, that's what I was thinking.)
As far as the differences between RIPEM and what you suggested:
1. Add explicit support in the RFC for self-signed certificates in
order to jump-start the process and address those users who were more
interested in issues of trust and trustworthiness, as opposed to a
formal hierarchical identification policy.
Great. This is what RIPEM does. I don't want to bore people with
explaining RIPEM's certification model. (I posted the relevant text
from the RIPEM user manual not too long ago when someone asked for an
example implementation.) Suffice it to say, I can easily configure
RIPEM to only hook me into RSADSI's Commercial Hiererchy a la RFC
1422. Or I can forget formal hierarchies and directly certify only
the people I want, thus implementing the "friends and family"
certification model (as Steve Kent once called it :-) ). You can also
have both. The self-signed cert simply allows the originator to
initiate communication without having to go through a third-party
issuer.
2. Support a simple e-mail based certificate-issuing responder
service that would have used the fact of e-mail connectivity as a
basis for a PCA policy model for identification. As I recall, RSA
indicated their willingness to support such a service. This policy
would clearly lie somewhere in between the RSA Commercial Hierarchy
and the Persona PCA policy models for identification purposes.
Billing for such services wasn't discussed, but it might be
reasonable to charge $30 to $50 per 10 users per e-mail account or
domain name, rather than trying to bill for $1 to $3 per user
certificate. (TARNSTAFL - There ain't really no such thing as a free
lunch.)
3. As part of this compromise between the medium-high
integrity/well-structured systems that are required by most large
corporations (witness Paul Lambert's excellent comments recently) and
the low integrity, low cost, anarchists VolksMail PGP approach, we
would adopt the use of the rfc822 e-mail name as a distinguished
name, as an alternative or in addition to the organizational person
or residential person DN model. I even offered to host a free or very
low cost X.500 directory service to facilitate such an effort, and
would have been happy to deal with the problem of aliasing back and
forth between the more conventional forms of DNs.
Sounds great. As long as the email address fits in a distinguished
name, RIPEM works fine with this. (Contrary to early releases which
had straight string-type identifiers, RIPEM is now X.509 certificate
based.) Just for my benefit, out of all the schemes I've seen for
sticking email addresses in distinguished names, which one do you
like?
- - Jeff
-----END PRIVACY-ENHANCED MESSAGE-----