pem-dev
[Top] [All Lists]

Re: CRLs: COST-PEM Solutions

1993-11-09 13:58:00
Sead,

Negative comments you received in response to the COST-PEM policy 
statement may have been based on the fact that you claim to comply 
with the PEM RFCs, then include explicit deviations from the RFCs.  
That is the sort of thing that violates the "Truth in Advertising" 
concern raised earlier on this list.  Additional facilities such 
as CA-based CRL distribution are fine, so long as they are not 
provided in lieu of the required facilities cited in the PEM RFCs.  
The criticism that the COST-PEM system is non-interoperable is 
correct;  a PEM user should be able to retrieve a CRL issued by 
ANY CA by issuing a request to the user's PCA.  As defined by your 
policy statement, this request would fail and hence the COST-PEM 
PCA is not interoperable.

As noted in one of my messages last week, the PCAs merely act as 
access points to a comprehensive (global) CRL database.  The 
database itself is maintained by the IPRA and, over time, can be 
eliminated when suitable directory facilities become available, as 
noted in 1422.  So your comment about PCAs being "godfathers" 
seems ill-founded, based on the rationale you cite.

I agree with your observation that the CAs are closest to the 
users and have the greatest interest in making sure that CRLs are 
accurate and available in a timely fashion.  However, that does 
not imply that the CAs must provide database services that make 
CRLs available to the PEM user community.  Analogously, one can 
argue that a town bureaucracy is closer to its employees than a 
regional phone company, but that does not imply that the town 
should publish a phone book for its residents.  Many towns in the 
U.S. do publish their own phone directories, but they are often 
meant for local use, by the residents, and are not considered a 
substitute for directory services offered by the phone company.

I cannot agree with your example of a corporate CA hierarchy and 
the statement that "The lowest, human certificates will  be  
issued  to  persons  as "Financial  Director" and if his/her 
certificate (or private component) is misused, THAT DEPARTMENT  
(AND  NOBODY  ELSE) WILL  HAVE SERIOUS CONSEQUENCES."  I sincerely 
doubt that misuse of a certificate or private component by the 
financial director of a company will affect only the finance 
department.  Rather, it has the potential to affect the whole 
company.  While a hierarchy often has the benefit of putting 
administration closer to those most directly affected, there are 
limits to this rule of thumb.  Moreover, there is no reason to 
believe that, in general, a departmental level CA (to use your 
example) is well equipped to maintain the computational and 
network resources to provide high quality CRL access.

There is a difference between a CA being responsible for issuing a 
current CRL at prescribed times and making that CRL available to 
the world.  Your comment, "So, what do we (as PCA far
"above" that Department) have to do with the  responsibility
of  their  certificate management and how can we (by keeping
CRLs) guarantee to ALL their customers that each certificate
of that Department is still valid." incorrectly characterizes the 
function of a database holding a CRL, perhaps because of the CRL 
service COST has elected to provide.  A CRL database need not be 
trusted to contain the latest (scheduled) CRL, in so far as the 
date fields in a PEM CRL provide sufficient information to 
indicate if a given CRL is the most recent (scheduled) CRL issued.  
The COST-PEM PCA, if it were operating as required in 1422, merely 
would be providing a convenient access point to a global CRL 
database.  It is still the responsibility of each CA to generate 
and sign its CRL in a timely fashion and to transfer it to the PCA 
for storage in a timely fashion.  If we had a global directory 
system (as envisioned in X.500 and X.509), there is no assumption 
that each CA would operate its own DSA.

You cite a model in which each user retrieves every certificate  
required to validate every incoming and outgoing message.  While I 
cannot say that a user is prohibited from adopting this model of 
operation, I can and do say that your vision of what constitutes 
"due diligence" is questionable and not in keeping with current 
paper world business practices!  The checks I sign and which are 
accepted as valid by my bank are NOT verified against the 
signature card on file with my bank, even when they are for 
thousands of dollars!  I get a paper receipt from an ATM when I 
make a deposit, but that receipt is almost worthless as it 
reserves the right of the bank to question the quantity of money I 
claim that I deposited.  Yet millions of customers opt for ATM-
generated receipts and the convenience of teller-less banking.  I 
think it extremely unlikely that MOST PEM users, even in a 
corporate, fiduciary environment would find the need to operate in 
the cache-less mode you envision.  I know of very high security 
systems using analogous technology that certainly do NOT operate 
in this fashion (mindful in part of the enormous, generally 
unnecessary burden it would impose on the communication system).

I also take issue with the example you cite to support the 
superiority of CA-based CRL distribution.  A user must report his 
suspected compromise of keying material to a CA or a CA must make 
a determination that the user's DN is no longer accurate.  Once 
either of these events takes place, the CA can generate a new CRL 
(or he might wait for the next scheduled update), and use his 
private key to sign it.  Finally, the new CRL becomes available to 
the community as a whole once it is posted to a server.  The 
electronic aspects of this process can take place very quickly, 
but the human, procedural aspects may take varying amounts of time 
depending on the individuals and the organizations involved.  It 
is not at all clear that a user who reports his key compromised at 
12:00 will see a CRL available at 12:01.  Not all CAs (I expect 
relatively few) may choose to provide 24 hour personnel support 
for this process, yet business may be conducted, worldwide, on a 
24 hour basis.  Not all CAs may be prepared to operate highly 
reliable servers for CRL retrieval.  Finally, it is not clear that 
the delays involved in posting a newly issued CRL to a server need 
be significantly different when the CRL is posted to a local (but 
securely isolated) server operated by a CA vs. a server operated 
by a PCA or the IPRA.  Note that the automated nature of the 
message exchange involved in posting a CRL from a CA to a PCA does 
not require human intervention at the PCA, so there is no 
corresponding need for 24 hour manning by PCAs (and/or the IPRA) 
to receive CRLs and make them available to the community.  To me 
it seems more likely that the IPRA and/or PCAs can expend the 
resources to provide highly reliable CRL service for their users, 
compared to individual CAs.

The network implications, when viewed globally, for the current 
PCA/IPRA CRL service may well be less onerous than your proposed 
approach because a single query can retrieve multiple CRLs for 
different PCAs/CAs.  Robust CRL servers operated by the much 
smaller number of PCAs/IPRA can be more reliable than hundreds of 
thousands of CRL servers operated by CAs with highly variable 
levels of availability.  The current PEM architecture which you 
describe as "perfect" is not independent of the PCA/CRL design, 
they are all part and parcel of the solution.

I worry that the COST-PEM view of the role of PCAs may be skewed 
by the fact that COST is a supplier of PEM software and hardware.  
Perhaps that motivates a philosophy that minimizes the 
responsibility of the PCA.   Again, let me emphasize that I have 
no objection to the COST PCA requiring its CAs to provide CRL 
access locally, but if the COST PCA fails to act as an access 
point to the global CRL database, then COST will be offering a 
non-compliant service that will prevent its CAs and their users 
from being part of the PEM system (as their CRLs will be 
unavailable to the rest of the PEM community via the mechanisms 
specified in the RFCs).

Steve


<Prev in Thread] Current Thread [Next in Thread>
  • Re: CRLs: COST-PEM Solutions, Steve Kent <=