-----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,
f6JbA5j9u3MiDN3bnLIsdl0mDPGeCfmXO9zDf65XPWhB8EnWg2RrBA7EHQM/lajp
3JKpXv8Xqkhlrt3D/dum3Q==
Dear Mr. Kent:
Regardless of all your latest comments to the recent
discussions on this list, I am still convinced that the
"distributed PEM" model, which we advocate in our
discussions and implementations is technically more
appropriate for MOST OF THE FUTURE (on-line) CAs than the
"centralized" RFC 1422 model. Not to mention business or
even political implications, being "tied-up" to a *BIG* PCA.
But I will leave this topic for later theoretical and
practical considerations.
In this message I would like only to reply back to your
comments related to our current COST-PEM implementation:
1. It is true that our CURRENT version [ COST-PEM v 1.1 ]
is not fully PEM-RFC compliant. We have stated that clearly
in our PCA PEM Policy. This is only because of our limited
time/people/money resources, so we wanted to get out the
first functional version of the COST-, may I call it: "PEM".
2. However, our next version, expected around Jan 1st, 1994
will be in fact more RFC-compliant. We will introduce the
full DN scheme, and we will also, besides keeping the CRLs
with CAs, send them regularly to our PCA. So our next
version will be exactly as you suggest, RFC-compliant, with
our "distributed CRL system" as additional feature.
3. As you pointed out several times "... current PEM CRL
database design is intended as an interim measure which
mimics the functionality of X.500 (for CRL retrieval)."
Well, don't you agree that our current "distributed CRLs"
model mimics that standard closer than the official RFC 1422
model ?
4. As far as I know, none of the existing PEM
implementations is fully RFC-compliant, but this "negative
attribute" is again and again attached only to our
implementation. Just to mention that the full compliance of
all implementations will be possible only when the IPRA
becomes operational. Until then, all implementations will
be "lonely islands", as they are in fact today and I am
convinced that even the accumulations of CRLs with PCAs will
not remove that attribute, since, of course, that is not the
only RFC-compliance requirement.
5. In this context I would like to suggest to treat the
RFCs flexibly. I know that standards are to be obeyed, but
also to be tested in practice and improved. I am afraid
that strict requirements to stick completely and formally to
X.500 (and constructs coming out of that standard) could
make PEM to have the same destiny as X.500 directories! If
some practical solutions show more functional, they should
be considered and accepted as improvements of the basic
standard.
I hope that with our next version [COST-PEM v 2.0] and our
practical experiences we will be able soon to prove our
opinions.
Regards,
Sead Muftic
COST Computer Security Technologies
Stockholm, Sweden
-----END PRIVACY-ENHANCED MESSAGE-----