[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on the draft
"Angelos D. Keromytis" <angelos@gradine.cis.upenn.edu>:
> Just some thoughts, after having read the draft.
>
> It'd be nice to be able to have the same certificate signed by
> more than one entities; the current scheme allows only one issuer per
> certificate. This can be resolved by moving the issuer and validation
> fields in the signature field (so that only the signature field is
> entity specific).
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.
> Also, i'd like to be able to have multiple values per field; so, i
> could have
>
> NAME: Angelos D. Keromytis
> NAME: Aggelos D. Keromitis
> NAME: The One And Only
>
> and any comparison of (NAME, somestring) would yield true if
> somestring was any of the above.
Multiple authorizations are permitted by the spec, including multiples
of the same type. It does bring up a matter I had not thought about,
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.
> Having the ASCII version of the certificate as the "default" (parse
> that instead of the binary) makes it easier to parse certificates that
> use attributes that are not understood by this application.
> This has the advantage that the application can parse a certificate
> which has fields not understood but also probably not of any interest
> to it. This can be done in the binary certificate as well, but
> requires special provision.
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.
>
> 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.
> Also, some form of certificate dependency; i would probably have some
> certificate that has basic information about me. Then, when a bank
> wants to issue me a bank account certificate, they just issue a
> complementary one (one with the information that's not included in the
> base one) which "requires" the base certificate.
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.
This idea really shines when you realize that the bank in your example could
simply have this certificate, issued to no one in particular, which said that
if a certificate of the predicated type existed, it was good for the specific
privilege, then the bank officers need only to issue that cert once, and your
personal account cert would, in the presence of that policy cert, give you the
privilege. This is automatic, and everything can be as [BFL] suggested, and
simply stated in terms of policies. I've put this idea forward to some of
our administrative folks here and gotten some very approving responses, since
it would eliminate a lot of boring and error-prone work on their part with no
loss of security.
brian
Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@primary.net
One Bell Center, Room 23Q1 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 331 2755
Follow-Ups: