[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My two pennies
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----