[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft of SPKI certificate internet-draft



Apologies to those on the list who didn't get in on this discussion from
the first.  I don't think that it should be too hard jumping aboard, however.

cme@cybercash.com (Carl M. Ellison):
> frantz@netcom.com (Bill Frantz):
> >We seem to have a number of cert types, e.g. CRCert and Deleg cert.  These
> >seem to me to be really uses of the standard format.  We probably need a
> >place where all of these are specifically described.  Perhaps chapter 8,
> >examples is the right place.
> 
> [...]
> How about you give this comment on the whole list and we can discuss it
> there? (at least get the discussion archived).  AFAIAC, there is only one
> certificate type.  CRCert is a process, not a certificate.  DELEG is an
> attribute of every cert.

I second the emotion; or should I say, first, since I mentioned earlier
that we did not perhaps make it clear that a CRCert is not a cert type
per se.  Actually, I thought that that was what Bill was saying.  If he
was, I'll agree and say that I'd like it to be clearer.


> >5.5, p32:  Add the following (or something like it) to the end of the
> >section:  "Designers should note that unless the surrounding system
> >provides mandatory access controls, effective delegation is generally
> >possible without using the formal path of certificate delegation."
> 
> I can't understand these words the way they are here.  Can you rephrase what
> you mean?
> Are you just saying that if access control is loose, delegation may not be
> an issue?

I made no response to that because I thought you would understand it.
Since you didn't either, I'll pipe up and ask for clarification too.


> >Also, should the MAY-DELEGATE default be * instead of 0?  I'll just suggest
> >the change and then shut up :-).
> 
> :)  Of course, I believe it needs to be 0 :)

I tend to side with Bill here, Carl; not because procedurally the permission
to delegate should not default to zero, but because parsing efficiency will
be improved if the more frequent option is the default.  So if a chain stops
at a non-delegatable cert(there wasn't a lot of discussion of this, but I
think it still holds), that means that only the last one in a chain will
be zero, and for chains of three or longer the zero-delegates will be in
the minority.  But I may be talking myself out of this, because we really
want to trade mostly in CRCerts, which will all be zero-delegate if I have
it right.  Someone else want to dig me out of this?
 

Brian Thomas - Distributed Systems Architect  bt0008@entropy.sbc.com
Southwestern Bell                             bthomas@cdmnet.com(or primary.net)
One Bell Center,  Room 23Q1                   Tel: 314 235 3141
St. Louis, MO 63101                           Fax: 314 331 2755