[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on the draft
-----BEGIN PGP SIGNED MESSAGE-----
In message <3.0b11.32.19960903123134.00678078@cybercash.com>, Carl Ellison writ
es:
>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.
>>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
>
>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
-----BEGIN PGP SIGNATURE-----
Version: 2.6
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMiyIab0pBjh2h1kFAQE0/gP+Mh+4P/oXEtuTkzIOeNGxqBfrtndNGZUD
jNYBecZ4YBjS+pye8ZS7oG3WiYxsegIxW4dUq5n4BuXh6hTkbYBFMsn5i+w4TlDC
HBrN+NRv4y20dn/uNfGDdtgElcX4/FS6CD8BLG1ec5VBjTNOPhT6OujRh5yzJ8G5
uVD0wKHThWU=
=L2NC
-----END PGP SIGNATURE-----
References: