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

Re: Thoughts on the draft


In message <3.0b11.32.19960903123134.00678078@cybercash.com>, Carl Ellison writ
>Are you thinking of "certificate" as "bundle of information, some of which
>includes the specific authorization requested"?
Yes, up to a point. If one signs a certificate, he has to make sure
that all the information he signs is valid.

>Your approach is interesting.  Can you send more, to help me understand it?
The idea is that you initiate the parser over the certificate, and
build some state. Then the application can check whether all fields
are there (spki_require()), and if some are missing return an
indication; ask for the value of a particular tag (spki_value()); get
all the values of a particular tag (spki_dump()) or the number of
values (spki_count()). There is special handling of signature tags.
This means that an application can then construct any sort of checks
(K out of N, has to have 2 names, has to have an ACCOUNT tag and a
MORTGAGE tag, his name has to have 3 e's in it etc.) without the SPKI
implementation library caring particularly about it. It very much
reminds me of cgi-bins, where you pass a bunch of values to the script
and then it does all the work; WWW people just mandated a format for
passing these values to the scripts; it's up to the applications to
handle them.

Of course, the library could include higher level calls (such as,
verify_trust(public key1, public key2, auth-tag)).

>This *does* leave the developer world open to the problem that those two
>different verifiers might co-exist for a while so that each has a user base
>and then some certificate issuer decides to support both -- but can't.  Auth
>tags can be made unique without going to OIDs or anything as cumbersome.
>They can include the domain name of the verifier -- or a large random number
>expressed as text.  Alternatively, we can create a web page for allocation
>of new <auth> tag names -- giving those already allocated, the name of the
>verifier and the meaning (and format) that verifier is using.
And if you have more than one type of authorization in the same
certificate, it could prove tricky.

>>ISSUER: You friendly police department
>>NAME: Foo
>>SUBJECT: 1, abcdef
>>ADDRESS: there
>>SIGNATURE: somevalue
>>ISSUER: SomeBank
>>REQUIRED: 1, abcdef
>>ACCOUNT: 123
>>SIGNATURE: someothervalue
>The syntax is off, here.  The SIGNATURE needs to be outside the BEGIN/END
>cert body -- so that a given cert can have multiple signatures.
I don't see why the placement of SIGNATURE makes any difference;
signatures should compute over all fields in a certificate except
other signature fields. The only case when you'd want to sign a
signature tag is when you do incremental certificates, and that's
easily distinguishable.
- -Angelos

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