RE: Charter Revision

["Flanigan, Bill" <[e-mail]>]

Hello Larry,

	Decided to add my nickel's worth.  Please see "BF:" inline comments
below.

Best regards,

Bill Flanigan
> ----------
> From: 	Larry Stoddard[SMTP:[e-mail]]
> Sent: 	Wednesday, June 30, 1999 5:32 PM
> To: 	Antonio Maña
> Cc: 	[e-mail]
> Subject: 	Re: Charter Revision
> 
BF:  Don't see a "business case" yet for a charter revision.

> The problem with the key/cert management approach is that it requires
> many keys. 
> 
BF:  Yes, and I currently don't see anyway to avoid this in the foreseeable
commercial future (but see last comment below).

> This will eliminate smart card based solutions as there is
> not enough space to hold multiple keys and key histories. 
> 
BF:  Memory growth and cleaver memory use/management will help.  Then there
is physical size:  I wonder how many cert/key sets would fit into a palmtop
or kneetop?  Probably as many as one needs. 

> Unless you use
> multiple smart cards, which would mean playing musical smart cards to
> read all your mail.
> 
BF:  I think you will actually end up playing musical certs.  You will be
dealing with a large number of PKIs, as well as a number of cert flavors
that each PKI will have issued.  For example, a "modest" PKI might like to
issue nonRepudiation certs, dataEncipherment certs, and IPSec certs.  And
this hardly scratches the surface as far as the number of variations just
based on the PKIX profile.  (I'm ignoring for now the possibility of root CA
cross certification.)

>  [snip]
> 
> Also for those that lease PKI services there will be an additional
> charge for each cert issued, so there is an incentive to minimize the
> number of certificates required.
> 
BF:  But there seems to be not much incentive to do this as far as
commercial browsers are concerned.

[snip] 


> Issuing identity certs and then revoking them
> would seem to be an extreme way of handling this and means more work for
> LRA and CA administration, not to mention longer CRLs.
> 
BF:  Maybe not.  You might start with a "long-term" nonRepudiation cert as
the I&A basis for obtaining/issuing short-lived certs (SLCs).  If SLCs were
good for only one transaction (with validity periods of seconds or minutes),
CRL posting would not occur.  As for CA administration, this is already a
big problem--especially for big PKIs (with certs in the millions).  Just
think about the bottlenecks of, say, how many certs/second can be issued as
well as directory storage capacity.  So, perhaps, your concerns about all
those certs may go away because cert servers can't issue them fast enough
and directories can't store them!  A final note:  I'm not sure if this
thread needs to continue.  If it does, I really don't think it belongs on
the S/MINE list any longer. 

[snip] 

> Larry Stoddard