From: Sead Muftic <sead(_at_)dsv(_dot_)su(_dot_)se>
Date: Tue, 15 Jun 93 15:41:31 EDT
Message-Id: <56491(_dot_)sead(_at_)mars(_dot_)dsv(_dot_)su(_dot_)se>
To: jlowry(_at_)BBN(_dot_)COM, pem-dev(_at_)tis(_dot_)com
Subject: COST-PEM and Certificate Validation
Dear Mr. Lowry:
You and mr. G. Bailey have raised some very significant
questions, related not only to our current PEM implementation,
but I should say to the whole PEM specifications.
1. Our CURRENT PEM implementation does not distribute CRLs,
but one of the future versions will. Our current approach
is based on availability (by users) of CURRENTLY VALID
certificates, vs. all revoked certificates. After all,
those are that you need.
Please understand, the user needs the certificate of each CA
up to the root and a valid CRL from each CA. There is no other
option. Anything else is not sufficient.
2. I wonder, if you don't trust some CA to send you CURRENTLY
VALID certificates in the path of your partner, how can
you trust the same CA to send you the CRL, when both
messages are THE SAME TYPE of the PEM letter (MIC-ONLY).
Please note that CRLs are signed objects and are validated by the user.
Also, I don't have to ask the CA for certificates, they are signed
objects. They can be supplied to me from anyone, including the originator
and I can validate them at my leisure with no direct interaction with
the originator's CA at all !
3. The problem of stolen certificates (challenged to our
implementation !) is in fact the problem of the "delay"
period. But that period exists even in current PEM RFCs,
since CRLs are distributed only periodically. I wonder
how mr. Bailey would solve his problem of stolen
certificate in the period while victim's partners still
haven't received the CRL.
I believe that the problem is not stolen certificates but stolen
private components. There has been much discussion on this list
about the trust which should be applied to systems like PEM and the
general concensus is that one should continue to employ traditional
procedural measures until the system is well understood in deployment
and use. i.e. One should not attempt to use a single signed message
for anything important but should employ additional methods like
witnesses, face-to-face meetings, notaries, etc.
4. The problem of criminal family, i.e. false CA: In our
implementation, in order to keep strict hierarchy of
CAs, that is not possible, since our every CA "knows"
its upper level CA and its subordinate level CAs.
If CA structure is "open system", so that any entity
being able to perform CA functions can apply and be
registered by any other CA, how the hierarchy can be
guaranteed.
The question is: do you want to accept all legal liability for actions
a user takes when that user relies on validity of a message ? That is the
position you place yourself in when CRLs are not available for validation by the
user. One does not need a criminal CA but only a CA who makes a mistake in
responding to a validation request.
5. Regardless of our "acceptance" of the necessity of CRLs,
I must admit that I don't see even in the coming versions
of our system how they will be implemented, since, as much
as I understand PEM RFCs, EVERY USER MUST HAVE ALL THE CRLs
of ALL CAs above ALL OF HIS PARTNERS !!! Next, when some
user sends a new certificate to CA, i.e. declares the current
as revoked, how that CA will know where (around the world)
that user has distributed his certificate and where to send
the CRL.
It is true that every PEM partner must have the CRL of every
CA in a certificate hierarchy they wish to validate. Because it
is "hard" doesn't remove the requirement. Note that other PEM
systems exist which meet this requirement. I have implemented
a secure X.400 system using certificate based key management which
meets this criteria. Of course I have the advantage of a DUA and
directory system to fetch CRLs and certificates when needed,
but I also support dial-up users who don't have this access
and must receive them as message bodies.
Note that there has been extensive discussion on this list (available
in the archives) on how to distribute CRLs. One can adopt a push
and/or pull model, in fact, there are CRL servers currently running.
I'm sure you can ask those folks for help.
I would like to emphasize again that IN THIS STAGE and IN THIS
VERSION of COST-PEM system, we didn't pay so much attention
to the CRLs, what I have explicitely stated in our PCA
policy. Therefore, I do not claim that our system is fully
in compliance with PEM RFCs, but I am sure that it is
WORKABLE and represents a good basis for initial practical
experience of our (future) users and a good basis for
further improvements.
I disagree heartily. Your system is not PEM compliant. It
does not meet critical portions of the specifications. You may
be correct that much could be learned from experience using your
system but you need to come into compliance if you are going to
interoperate with any other PEM system that I am aware of.
Please note also that your certificates are encoded incorrectly.
They contain Names which consist of a single multivalued RDN.
This is an incorrect interpretation of how Distinguished Names
should be constructed. In addition, if you intended this to be
a DER encoded certificate then it violates the rule for encoding
SET OF components which must meet the rule regarding encoding
according to increasing order of their octet value. This problem
does not occur in single value RDNs.
John Lowry
Certificate decode follows:
*****
SEQUENCE (247 octets):
SEQUENCE (202 octets):
INTEGER (1 octets):
01
.
SEQUENCE (13 octets):
OBJECT IDENTIFIER (9 octets):
1 2 840 113549 1 1 2
NULL (0 octets):
SEQUENCE (58 octets):
SET (56 octets):
SEQUENCE (9 octets):
OBJECT IDENTIFIER (3 octets):
2 5 4 6
PrintableString (2 octets):
73 65
s e
SEQUENCE (9 octets):
OBJECT IDENTIFIER (3 octets):
2 5 4 10
PrintableString (2 octets):
73 75
s u
SEQUENCE (15 octets):
OBJECT IDENTIFIER (3 octets):
2 5 4 11
PrintableString (8 octets):
64 73 76 74 2e 64 73 76
d s v t . d s v
SEQUENCE (15 octets):
OBJECT IDENTIFIER (3 octets):
2 5 4 3
PrintableString (8 octets):
63 6f 73 74 2d 70 65 6d
c o s t - p e m
SEQUENCE (26 octets):
UTCTime (11 octets):
39 33 30 34 32 36 31 32 30 31 5a
9 3 0 4 2 6 1 2 0 1 Z
UTCTime (11 octets):
39 34 30 34 32 36 31 32 30 31 5a
9 4 0 4 2 6 1 2 0 1 Z
SEQUENCE (58 octets):
SET (56 octets):
SEQUENCE (9 octets):
OBJECT IDENTIFIER (3 octets):
2 5 4 6
PrintableString (2 octets):
73 65
s e
SEQUENCE (9 octets):
OBJECT IDENTIFIER (3 octets):
2 5 4 10
PrintableString (2 octets):
73 75
s u
SEQUENCE (15 octets):
OBJECT IDENTIFIER (3 octets):
2 5 4 11
PrintableString (8 octets):
63 6f 73 74 2e 64 73 76
c o s t . d s v
SEQUENCE (15 octets):
OBJECT IDENTIFIER (3 octets):
2 5 4 3
PrintableString (8 octets):
63 6f 73 74 2d 70 65 6d
c o s t - p e m
SEQUENCE (34 octets):
SEQUENCE (13 octets):
OBJECT IDENTIFIER (9 octets):
1 2 840 113549 1 1 1
NULL (0 octets):
BIT STRING (17 octets):
00 30 0e 02 09 00 c2 27 77 72 33 ec 76 93 02 01 03
. 0 . . . . . ' w r 3 . v . . . .
SEQUENCE (13 octets):
OBJECT IDENTIFIER (9 octets):
1 2 840 113549 1 1 2
NULL (0 octets):
BIT STRING (25 octets):
00 80 00 88 d5 69 e6 09 c5 55 df f8 a0 46 22 4a 12 bb 92 f2 d3 33 77 41
0b
. . . . . i . . . U . . . F " J . . . . . 3 w A
.