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

Re: Thoughts on the draft

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


In message <199608272308.SAA09092@entropy.sbc.com>, "Brian M. Thomas" writes:
>
>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.
>
I was refering to section 3.2.1, but it might have been a bad example
after all.

Another example:
Imagine an international Passport Certificate, which holds information
about your person (name, address, nationality etc); each time you want
to travel to some country which would require some sort of visa, you
just go to their embassy and get your certificate signed (and it would
expire when the visa would expire). Now, instead of having one
certificate for each country, it might be easier to have just one
certificate and multiple signatures.

It also seems that some support for multiple signatures is there
already, even if just to support the DUAL-SIG: attribute.

>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)
> 
But it does not say anything (for or against) duplicate auth fields.
If there is support for it, it should be explicitly declared.

>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.
>
I agree on the simplicity part, however i believe we can have shared
certificates without using ASN1 or some other similarly (or more)
complex monstrosity.

>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 yourKe
>y
>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 t
>o
>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.
>
I find however that this example is farther away from the PolicyMaker
mindframe; what i have in mind is essentially a simplified (?) PM: one
just provides a library that gives access to the internals of a
certificate (chain) and then leaves the application do all the hard
work. The analogy with WWW cgi-bin scripts comes to mind (imagine the
attributes of a certificate as the variables passed on a script, which
checks their validity). I'm not sure yet if this is a/the correct
approach, but it seems so (to me) at this point.

>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.
>
I would be nice to have shared certificates though. For example,
if X and Y are applications which are different but both trust an
application Z's certificates, then it would make sense to just have Z
create sharable certificates and X/Y use those fields of the
certificate they really care about, instead of having Z create
certificates depending on who it is destined for (of course, this is
assuming that X's and Y's certificates are not all that different).
- -Angelos


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

iQCVAwUBMiOIEL0pBjh2h1kFAQEn6gQAlaHpoI8wRIjw37BkP3Su098V9bEiBc4o
VczY6IbfODzinJ1xx18yBfPkOJFZoHjogI80qlToj6xjiUpZKSCDnuwxh8r6qipU
VN5Nbc5bO0wT/2TzLmUUFwHQar41kKRInRthoqdoaINz1O3sdcSHjfBAK965xh6A
vJNsgEiABSc=
=jXtQ
-----END PGP SIGNATURE-----
References: