Re: Revised Access Authorization Spec

Ari Luotonen (
Fri, 17 Sep 93 10:34:45 +0200

> > * A given server supports a fixed set of authentication schemes, i.e.
> > this set may not vary according to which ducument is being
> > accessed. Otherwise this would complicate either rule or ACL file.
> I don't think this should be a general restriction. Plexus will have
> no problem doing this and configuration doesn't have to be unduly
> complicated (e.g., you could simply put the config file in each top-level
> directory instead of having a central one).

Top-level directory is not good (the same reason as before, links in file
system). But I have changed my opinion, I agree; how about changing
"protect" rule (because it has already become 90% redundant -- don't ask
me how I get these figures... ;-)):

protect <template>
protect <template> <authentication>
protect <template> <authentication> <protection>

<authentication> is something like "basic", "pubkey", "Kerberos", etc.
<protection> is something like "NONE", "MIC-ONLY", "ENCRYPT".

And there would also be two additional fields in rule file:

default_authentication <authentication>
default_protection <protection>

Which are used if <authentication> and/or <protection> is not provided
in "protect" rule, or if there is no "protect" but there is an existing
ALC file.

> > * A reply from a protected server starts with a status line:
> >
> > HTTP/1.0 202 Privacy enhanced reply follows
> Why define a new code? IMHO, all this information should be in headers,
> not on the status line. You even already defined headers for this, so
> this is really just duplicate information. Does it really serve any
> purpose?

Well now that I think about it, it doesn't serve any purpose. Ok, it's
going bye-bye.

> Oh, BTW, TimBL had suggested using WWW-foo: for the new headers we define
> to avoid collisions. Of course, any headers you are using from existing
> specs or proposals are fine.

Ok, so they will be:

WWW-Body-MIC: These could be only one MIC-Info: with
WWW-Header-MIC: multiple subfields. How about it?

Authorization: This is already in use, and was in HTTP spec
when I started on this, so no "WWW-".
Key-Info: These
DEK-Info: two are like in PEM.

-- Ari --