-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type:4,MIC-CLEAR
Content-Domain:RFC822
Originator-Certificate:
MIIBVjCCAQACAQIwDQYJKoZIhvcNAQECBQAwOzELMAkGA1UEBhMCc2UxCzAJBgNV
BAoTAnN1MQwwCgYDVQQLEwNkc3YxETAPBgNVBAMTCGNvc3QtcGVtMBoXCzkzMTAx
MTE1NDZaFws5NDEwMTExNTQ2WjA3MQswCQYDVQQGEwJzZTELMAkGA1UEChMCc3Ux
DDAKBgNVBAsTA2RzdjENMAsGA1UEAxMEc2VhZDBaMA0GCSqGSIb3DQEBAQUAA0kA
MEYCQQDhmzekA4NjLKE7iaJWmBLppyKDjiTQ0knHg7HEkFQu4kQXciS6iJcjb1dy
Z5ck04CqQgWn/d5qItzIB4uQafrZAgEDMA0GCSqGSIb3DQEBAgUAA0EAHROMOuYV
08+jAyTTC1olAr8+IbYMzd7xAOaLa+5CWT2hLbKEsa0WVk7f/s7NEZ3/GqaWDXu/
wAn1JCufjSnBwg==
Issuer-Certificate:
MIIBXzCCAQkCAQwwDQYJKoZIhvcNAQECBQAwQDELMAkGA1UEBhMCc2UxCzAJBgNV
BAoTAnN1MREwDwYDVQQLEwhjb3N0LmRzdjERMA8GA1UEAxMIY29zdC1pbnQwGhcL
OTMxMDA4MTAwN1oXCzk0MTAwODEwMDdaMDsxCzAJBgNVBAYTAnNlMQswCQYDVQQK
EwJzdTEMMAoGA1UECxMDZHN2MREwDwYDVQQDEwhjb3N0LXBlbTBaMA0GCSqGSIb3
DQEBAQUAA0kAMEYCQQCchGJ82EnE6wotGBRSzQXzPTtwADscN1EO3fEpYZDeD4qc
2GbaLzJ1z1qkj0N8mSce53FHtTESPZvCXejV5V4bAgEDMA0GCSqGSIb3DQEBAgUA
A0EAYRMcwXUJV91IPEcLvWsVo905CkKUmxTmDyhYgndMZ92eamMUtZbrjKNk2gyu
e4+d15iV4mKrzyScGLeAxHlnAQ==
MIC-Info:RSA-MD2,RSA,
bNR4goF9f3Fp3j/FKIqxfdSIolHWf9bJPZbiS3T4sg2qh1gYEfI3pSxIcoeyZLhy
Wl8drvwoTpRV/gA4wcKb6w==
Dear PEM Friends:
First I would like to inform Bob Jueneman that in our
current PEM improvement activities our first priority is to
extend our current PEM implementation somewhat "closer" to
the official RFC model, i.e. soon (I hope Christmas) we
will have the system which will:
a. use some "extended" form of the certificate, whatever
that form means,
b. our CAs will, in addition to storing CRLs locally,
send CRLs to our PCA, as required in RFC 1422,
c. our CAs will, in addition to distributing CURRENTLY
VALID Certificates (on request), what they do today,
distribute also
- CRLs (on request),
- results of verifications of signitures,
d. map somehow X.520 attributes to DNs, E-mail addresses,
etc.
Next, to those PEMers who are a little bit more
"conservative", I would like to guarantee that our next PEM
version WILL NOT violate any RFC requirement, all our
alternative ideas will be implemented as add-ons.
If everything shows functional and usefull, I hope this will
be a small contribution to the PEM business applicability
and, hopefully, if documented, to PEM standardization
process.
I believe that different, alternative to RFCs, suggestions
on this list are very helpfull to us. With our limited
manpower resources we will try to make some new steps in
order to test and prove these ideas.
I hope that alternative CRLs and Ca-functionality model are
not against PEM, quite contrary, for its future benefits.
My impression is that all these current disagreements on
this list come from the fact that PEM was originally
envisioned and designed as the "Secure E-mail System", but
today it is obvious that it may very nicely be functionally
extended to a broad range of electronic business
transactions, which do have a little bit stronger
requirements that just a secure E-mail.
Regards,
Sead Muftic
COST Computer Security Technologies
Stockholm,, Sweden
-----END PRIVACY-ENHANCED MESSAGE-----