Subject: RE: draft-ietf-ltans-pki-retention-01.txt
From: Carl Wallace <[email-masked]>
To: Michael Ströder <[email-masked]>, [email-masked]
Date: Fri, 27 Oct 2006 10:07:31 -0400
List-Id: <ietf-ltans.imc.org>

> HI!
> 
> Some comments to this draft:
> I fail to see how applications can efficiently query the 
> historic PKI artifacts. E.g. most times you want to query a 
> cert by issuer name/serial number. You also have to query the 
> CRL most recent at a specific time. How is this done?

By having a CRL that covers the lifespan of a CA, the need to search for a
specific point in time goes away.  A single CRL will suffice.  If the
community covered by a CRL is partitioned well, then even a cumulative CRL
should not be too great in size.  Applications would query for a CRL using
either a CRL DP in a certificate or query the issuer's directory entry.  In
either case, the historicalCRL entry would have a cumulative CRL and the
associated evidence record.  The discovery mechanisms are the same as
existing mechanisms.  There're no provisions for querying for issuer
name/serial number in this draft.
 
> In general: How's the relationship of entries of AUXILIARY 
> class historicalPKIEntity/historicalCRLDistributionPoint to 
> PKI entities? Do you have any suggestions which entries 
> should be extended by this class?

The new classes are peers to existing pkiCA and cRLDistributionPoint.  The
new attributes could be added and maintained throughout a CA's life, then an
evidence record generated at the end of the CA's life, for example.  
 
> More specific: Are attributes historicalCertificate and 
> historicalCRL supposed to contain several certs/CRLs and the 
> client has to sort it out? Do you think this scales?

If multiple cumulative CRLs are created and stored in the same entry, then
there's much for the client to sort out.  If a single cumulative CRL is
generated when a CA rekeys, for example, then there's not much to sort out
and the discovery mechanisms parallel the existing mechanisms.  For
certificates, clients may have to select from multiple certificates in a
similar fashion as they search for current certificates.  I think preserving
artifacts directly scales better relative to storing all artifacts in each
archived data object.
 
> How about looking at draft-ietf-pkix-ldap-pkc-schema? (last vesion at
> http://www.watersprings.org/pub/id/draft-ietf-pkix-ldap-pkc-sc
hema-01.txt)
> Even if you don't take the approach specified there the draft 
> raises some good points which could inspire 
> draft-ietf-ltans-pki-retention.

I'll give it a read.  Thanks.

> 
> Ciao, Michael.
> 
> [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Long-Term Archive and 
> Notary Services Working Group of the IETF.
> > 
> > 	Title		: Infrastructure Support for Retention 
> of PKI Artifacts
> > 	Author(s)	: C. Wallace
> > 	Filename	: draft-ietf-ltans-pki-retention-01.txt
> > 	Pages		: 14
> > 	Date		: 2006-10-26
> > 	
> > In most PKIs, directory servers are used to provide current
> >    certificates and revocation information to relying parties.  In
> >    situations where certificates must be validated relative 
> to a time in
> >    the past, relying parties often have no means of obtaining the
> >    necessary PKI artifacts.  This specification defines several
> >    directory attributes to support validation using historical PKI
> >    artifacts.
> > 
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-ltans-pki-retention-01.
> > txt
>