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

Re: Thoughts on the draft

-----BEGIN PGP SIGNED MESSAGE-----


In message <199608271900.OAA08412@entropy.sbc.com>, "Brian M. Thomas" writes:
>
>Some discussion of this has already occurred, but I'm curious as to why
>multiple issuers would be required.  If I, as issuer/verifier, find that
>someone else has also issued the privilege, what does it mean to me?  I
>trust no one more than myself.  If someone else grants the same privilege,
>it is not I who will verify that, but the one granting it.  That's really
>another certificate, one that someone else will be verifying, regardless
>of the fact that it may have identical semantics.  For privileges that
>require signatures by more than one party, you could use a single cert
>with several issuers, but it's easier to have a cert for each one, which
>can be combined by means of a policy cert, which I mention below.
>
The only reason for multiple signatures i can think of (other than a
policy that requires them) is simplicity; when someone asks for your
email certificate, you don't just go through a (potentially large)
database, but just hand them your certificate about email
(s/email/whatever) and he'll figure out if it's ok. You can do the
same by sending all your email certificates, but it's not as elegant IMO.

>Multiple authorizations are permitted by the spec, including multiples
>of the same type.  It does bring up a matter I had not thought about,
Must have missed that in the draft.

>which is the searching capability you mention.  The need, especially in
>cases like yours, for searching on a non-deterministic transliteration
>into a foreign character set, is one way the multiple auths idea could
>be used, but the search logic would have to work that way too.  That
>will be important in implementation.
>
Well, my idea of an SPKI implementation is a library of functions
which offers some basic services and you then let the program(mer) do
the rest; so, an example program in pseudo-C could be:

<includes here>

main()
{
 struct spki_state state;
  .
  .
  .
 spki_init(&state, buffer_holding_certificate);
 spki_require(state, "name", "signature");
 if (spki_check(state, "name", "Angelos D. Keromytis") == TRUE)
   return HOORAY;
 else
   if (spki_check(state, "name", "Aggelos D. Keromitis") == TRUE &&
       spki_elems(state, "name") == 1)
      return DONT_USE_THAT_NAME;
}

The
   spki_require(...)
is used by the application to define the fields on a certificate it
will absolutely need, so if they aren't there some appropriate error
can be returned to the peer, saying p.x. we need an EXPIRATION field.

>I'm going to take a stab at this, as having begun a reference implementation.
>You are, of course, dealing with an issue that has been dealt with at length,
>although no strong consensus was reached.  What you mean by the "default" is
>not really clear to me, however.  Obviously, ASCII (or UTF-8, actually, within
>the limitations of the display device) is more readable to humans.  However,
>the transfer syntax is by definition the machine readable format, and by
>design it is intended to be understandable even where unknown fields exist.
>If our encoding fails in that regard, we should fix it(one example has been
>noted already, in fact, to which I have not responded, and Carl has been busy)
>.
>Most importantly, however, is the form that the cert is in when the signatures
>are taken.  Where the ASCII format has options to suit the display format, the
>binary encoding must not, so that the signatures will check.
>
I won't argue about using the binary format to create the signatures.
However, it's not clear in the draft how two applications which
use these two lines in their certs respectively

AUTH: "NEXTVACATIONS", 69, a, b, c
AUTH: "POTENTIALCUSTOMER", 69, a, b, c

will be able to distinguish between certs they or the other application
created.

>> Multivalue attributes should be accesible in a structured manner:
>> 
>> SIGNATURE: {ISSUER:foo EXPIRATION: { TIME: endofuniverse TYPE: CRL }
>> 	    ALGORITHM:RSA 
>> 	    VALUE:0x8376812}
>> 
>> SIGNATURE.ISSUER == foo
>> SIGNATURE.EXPIRATION.TYPE == CRL
>> 
>
>I may be misunderstanding you here, but the internal form of the cert
>(after parsing) does just that.  If it's something not understood, it
>will just be in an unstructured area of the internal form and it won't
>be touched.  To stress again:  generally, because SPKI certs form explicit
>chains of authorization, a verifier will not be seeing valid certs that
>are not understood.  This makes the standard-making process much cheaper
>and quicker.  Everything that we have suggested in the draft are only
>that -- suggestions; any relying party is free to make its own choices,
>even, to a degree, within the suggested formats.

But why not take this (or a similar) approach, so that even
applications that create vastly different certificates can partly
understand a "foreign" certificate; besides, one might just be
presented a completely strange certificate by some rogue application,
or maybe different organizations have different formats; American
Express and Citibank will probably have different certificates, but i
can think of situations where Amex will issue a certificate for some
citibank account certificate etc.

>I'm thrilled that you bring up one of my favorite ideas.  The spec is, by
>Carl's admission, weak on this, and we've been putting off discussing it
>too much for a while.  But here's my current feeling about it:
>
>What you speak of is something I felt I had "invented" until Carl pointed
>out that I had gotten at least the seed of the idea from [BFL]:
>the policy certificate.  My current idea, which is just one of those
>currently floating around, is to have a field called PREDICATE or
>(after PolicyMaker) WHERE or DEPEND or POLICY or QUALIFY or... you get
>the idea:  the privilege is granted conditionally, upon satisfaction of
>a boolean-valued expression in this field, which has operators which
>evaluate the existence or non-existence of certificates of a particular
>type.  Note that, in all such cases, if the condition is met, then the
>certificate can be issued unconditionally for that user, because the
>issuer of the cert is itself the current verifier.  That's the idea
>behind the CRCert notion we speak of in the draft:  that any chain of
>certificates can be collapsed into a single certificate for future use
>internally or it can be signed by the verifier/issuer and passed back
>to the supplicant for future requests.
>
What i had in mind was something like:

BEGIN
ISSUER: You friendly police department
NAME: Foo
SUBJECT: 1, abcdef
ADDRESS: there
SIGNATURE: somevalue
END

BEGIN
ISSUER: SomeBank
REQUIRED: 1, abcdef
ACCOUNT: 123
SIGNATURE: someothervalue
END

Of course, you could then collapse the above two in a CRCert, if you
care to.
- -Angelos

-----BEGIN PGP SIGNATURE-----
Version: 2.6
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMiNPhb0pBjh2h1kFAQF78QP/UcbPbR2saJoT4ODIyMUvo+xBre4my/t3
zvbB4ReG4jksloWsJmj5PEyVWZUctyVqOG0qVNiSRjhlH5+CZBfwXrqV1FX1BH+v
5zwLidWJ9O3E+tnKa1M2fF30PCWFHnEJmYKDlJAUoG6isrF0ZXkmMaPY5fT10dR5
ya6fcpf1Np4=
=dIdi
-----END PGP SIGNATURE-----
References: