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

Re: My two pennies


On Mon, 31 Mar 1997, Carl Ellison wrote:
> At 03:57 PM 3/30/97 -0500, Marc Branchaud wrote:
> >(22) I don't understand the issue here.  If we're letting users define
> >their own object types (which is different from defining an <auth> type)
> >then I guess we should use local dictionaries.  Am I making sense?
> I was considering user-defined <auth> types with named parameters.  Each of 
> those parameters would have a user-defined object type.

Ah, I see.  It's a lot like functions in a program, where each function
uses its own, local naming context.  Well, now it really comes down to
whether or not we have more than one <auth> in a cert.  If it's only one
<auth> per cert (which I favor anyway), then I think we can use one global
dictionary for the entire cert.

IMHO the basic rule is to have one dictionary per <auth>, as different
<auth>s can each have a parm with the same name but use/define that parm
differently.  If we have multi-<auth> certs, the cert processing code
would have to track the different dictionaries, reducing simplicity.

So I say one dictionary / <auth>, one <auth> / cert, therefore one
dictionary / cert.

> >(23) If we do this, we should define a specific <auth> or set of <auth>s
> >for when this is the case, and also explicitly state that May-delegate
> >MUST be 0.  This, of course, complicates things.  What, exactly, is the
> >meaning when a non-key object is the subject of a cert?
> I was thinking, for example, of a signed purchase order or electronic check,
> signed code, ....

These cases are very different than delegating an authority.  Here I think
I'd prefer the ( assert ... ) structure mentioned earlier.  It makes the
distinction obvious.  Of course, (assert)s could never be delegated.

> >(25) It's always better to state things as clearly as possible.  I say put
> >the statement in the document.
> >
> >Finally, two syntactical points about the draft.
> >
> >- - For dates (4.1.18), don't make any fields optional.  It could make for
> >  interoperability problems, especially WRT hashing.  Also, make an
> >  explicit definition for midnight.
> How would you define midnight?  1997-03-31_midnight ?  If so, we have
> the problem of deciding whether this is the midnight which just happened
> a few hours ago as I write this or the midnight which is yet to come.

I'm thinking more of the case when HH:MM:SS is 00:00:00.  The question is,
is midnight the start or end of the day?  I say make it the start of the
day, so the clock would progress like this: 

Another point: when you said "taken to be 0" in the draft you should
really say "taken to be 00" to make sure that the two-digit format is
preserved.  In any case, I don't think any date field should be optional.

> >- - <valid> is defined as:
> >	<valid>:: <not-before>? <not-after>? <online-test>? ;
> >  Should it not be:
> >	<valid>:: ( <not-before> | <not-after> ) | <online-test> ;
> How are you using the ()s?  | is logical OR, so the ()s have
> no function here.
> I used ?s because I assumed someone would want to specify up
> to all 3 of these.

Sorry, my pseudo-BNF is really rusty.  :)

My main problem with your original definition is that it makes valid a
blank <valid> field.  Unless a blank <valid> is defined in the draft
("never expires"?) then the field should really be defined as "at least
one of" the three.

What I meant to say with my definition is "either <not-before> or
<not-after> (or both) x-or <online-test>".  Obviously, that's no good if
you want to have all three as a possibility.


Version: 2.6.3ia
Charset: noconv


Follow-Ups: References: