Cc: pem-dev(_at_)tis(_dot_)com
Date: Thu, 09 Dec 93 13:26:54 -0500
From: Steve Kent <kent(_at_)BBN(_dot_)COM>
Jeff,
You made some suggestions about turing parameters for
certificate validation:
1) All certificates and CRLs are required.
2) CRLs are required but may be obsolete.
3) No CRLs are required.
3a) CRL required from first level CA but not from higher levels in
hierarchy.
4) CA certificates can be obsolete (and PCAs as well)
5) User certificates can be obsolete
6) Anything is ok (PEM becomes a no-op) or a printf("All OK");
I think #1 needs some refinement. I asusme you meant to say all
certificate and CRLs are required and all must be currently valid.
This is the current requirement to avoid no warnings and obviously
represents the baseline.
Yes.
As for #2, I agree that how recent a CRL needs must be for it to be
acceptable is a local matter and really should be a parameter settable
by a system admin or even by the user. 1422 leans a bit in this
ditrection, noting that the form of warning about missing or old CRLs
is a local matter, but it does mandate a warning and maybe that could
be softened.
Agree.
#3 is a big jump from #2 and bothers me, while #3a is more reasonable.
I expect the IPRA CRL and the CRLs issued by PCAs to have very few
entries for a long time, so missing them or having them be old isn't
so terrible for most authentication purposes. missing a CRL for third
or lower tier CAs is more problematic. However, I agree that
the requirement for timeliness of the CRLs can be a local issue.
Perhaps 3 and 3a should be reversed in order.
#4 is a lot like #2. Again, PCAs should be stable and most CAs will
be as well, so having a CA or PCA certificate be obsolete may not
terrible. However, I also expect them to last for a while and for
inbound mail I think it reasonable for an originator to have a current
one, especially if the PCA/CA is smart and reissues its certificate
(with the same key) well in advance of the expiry date. For outgoing
email, if I'm fetching certificates from my local cache, this might be
a reasonable, local parameter as well.
#5 its too early to tell how much of a problem this may be. again, on
incoming mail, I expect a user to be able to have a current
certificate to put in his PEM header, unless his CA does a poor job.
if one accepts expired certificates AND doesn't require a curent CRL,
this leads to obvious vulnerabilities that could be exploited by an
originator . For outgoing mail, it's more of a judgement call.
#6 is included for completeness, right?
Yep!
I do worry that if each of these parameter groupings is separately
set, the resulkting interface can be pretty complicated and the
effects may hold real surprizes. Maybe a hierarchic ranking, if we
could agree on one, would help simplify the management interface and
avoioid undue complication for users. 1422 states that most of the
conditions cited above a merit a warning, but that the nature of the
warning is a local matter.
This is exactly why I proposed this as a tuning "knob." If we can agree
to the rank order of severity, it would make "tuning" of PEM implementations
by site administrators or end users much easier to do. The knob is sort of
a "how much do you care" indicator. I have also thought of two modifications:
1) Perhaps rather then being a knob you frob, the levels are an indicator.
The lower the number, the more trust you can have as to the authenticity of
the message.
2) Separate knobs for receiving a message and sending a message.
-Jeff