[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on the draft
> 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.
This confuses me. If the cert you speak of is one that says that I
receive mail at a given address, then it will be signed by me; there is
no greater authority for that statement, and no one else to vouch for
it, and as section 3.2.2 mentions, there is no motivation to lie about
this: if I do, your mail sent to me won't get to me, and whoever gets
it won't be able to read it. If it means (as in S3.2.1) that I own the
mailbox and it speaks for me, then the admin of the email domain is the
one who vouches for it. In neither case is more than one cert required,
except to establish trust in the issuer, but ultimately, you are your
own root, so to trust that cert, you have to certify its issuer (or the
root of a chain from its issuer). I have not yet found a requirement for
multiple issuers. Perhaps you could clarify further what you mean by
an email certificate.
> >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.
Yes. Sorry not to have quoted the section, but 4.1.5, paragraph 2 says,
"An SPKI certificate is assumed to contain 0 or more <auth> fields...",
and NAME is one kind of <auth> field. The wording was Carl's, and what
he meant by "assumed" is not certain. I would "assume", also, that it
didn't have *fewer* than zero <auth> fields...%> (sorry, Carl)
> 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.
The code example is reasonable, though "state" is not a name I would have
chosen for the internal form of the certificate.
I think there's some confusion here, and I think it stems largely from the
kind of thinking that has gone into X.509 designs. There's a concern that
has to do with whether the cert is composed appropriately for the relying
application. But since the relying application, or someone delegated by
the application, was the creator and signer of the certificate, the choice
as to the appropriateness of the certificate hinges mostly on the issuer's
key. In other words, if I issued it, I had better understand it. If I don't,
no problem; just refuse. In other words, no one else - no standards body,
no third party - is involved in the composition of the certificate. This is
*so* much simpler, and this is why *I*'m doing this, not because I hate ASN.1
or X.509 but because it's a simpler and more direct path to what I want done.
For my version of how this would work in pseudo-C, consider:
CERT *cert;
if((cert = findCert(myKey, yourKey, whatYouWantMeToDo)) == NULL)
return NO_YOU_CANT_DO_THAT;
if(!isValid(cert))
return CERT_EXPIRED; /* or, refresh by path specified in RENEW_LOCATION */
return GO_FOR_IT;
findCert's job is to look in its local cache, some repository service, in its
back pocket, under the doormat, etc. for a chain of certs from myKey to yourKey
which results in the permission specified by whatYouWantMeToDo. It would most
likely collapse this chain into a CRCert (if a single one didn't exist already)
and return it. The extra isValid() check may or may not happen inside that
function. If it were not an already-signed "real" cert, I could then choose to
sign and return it to you, so that our next interaction could be shorter. At
minimum, it could go into my cache so that the next search for this permission
for you would find it, and I would permit the action (GO_FOR_IT). I find this
much simpler, and I don't think I need any of that other stuff, and nothing
less than an explicit path of authorization from myKey to yourKey will satisfy
me anyway. I am therefore substituting this simple and rigid chain for all
the esoteric stuff which I hope some bored, underpaid, overworked operator
of a third-party certification service didn't get wrong.
> 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.
The main way that the distinction will be made is that app X won't generally
be looking at app Y's certs, because they weren't issued by app X or any of
its collaborating agents. If app X's administrator chooses to depend on, say,
a name certificate from another issuer, he will make sure his app understands
the certs issued by it before issuing the certificate granting that issuer the
trust over name-issuing. If the application deputizes another entity, for
example a user group, to dole out memberships in a group that it will honor,
the group administrator will generally just delegate the permission granted
by the app. The point is that these collisions will mostly be prevented by
structural means.
When I query my store of certs (wherever it may be) for a particular chain,
I am first looking for the issuer-to-subject connection and then for a specific
authorization. The <auth> sought will probably be an exact match, so little
understanding is actually required; either it matches, and it's what I want,
or it doesn't and I don't care.
> 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.
As above, to the extent that the question is meaningful, I believe it can
be fully dealt with by the fact that all of these matters are agreed upon
in advance by people who choose to authorize the use of the "foreign" certs.
By this authorization, the cert ceases to be "foreign" because if they chose
to authorize something, they would have to make sure their apps understood
what was being authorized. A "partial" understanding is not meaningful, to
my mind, owing to the more specific meanings that are intended to be expressed
by a more generalized certificate format. A certificate that can express any
kind of authorization can therefore be much more explicit about it.
> 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
Actually, there is some structural requirement for this anyway. Since the
subject key is not actually part of the certificate, you have to get it somewhere,
and the somewhere is named by the SUBJECT-CERT field. Remembering that your
choice to issue this key was most likely made interactively by a human, this
requirement could be met, because that human made the choice as to how to compose
that certificate.
A lot that is not said often here in this list is still very important: that
dealing with the separation of administrative and run-time duties. Most cert
composition is done, of course, by administrative processes, mostly run by
humans. Choices are made, and the certificates express those choices. The
example you cite above is a human-interactive choice, for one customer. The
policy certificate could let the human make that choice once for all possible
clients, and the applications could enforce that policy without human intervention.
This is the other reason I like this stuff.
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: