[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on the draft
At 01:06 PM 8/27/96 EDT, Angelos D. Keromytis wrote:
>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).
This sounds good. How does it differ from a certificate with a single
issuer which refers to some external body? That is, we could make a
#include analog
INCLUDE <hash alg>,<hash of body>
to achieve the same thing. Am I understanding you correctly?
>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.
That sounds very good to me and should be consistent with the spec. If it's
not written that way, I'll change it.
The idea of allowing multiple <auth> statements in a single cert was to
avoid multiple certs as a matter of storage and comm efficiency.
OTOH, there's a certain amount of logical (ie., programming) efficiency from
allowing only a single <auth> in a cert body and not permitting INCLUDE,
while we're at it.
>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 don't see the difference. <auth> fields in a binary cert
AUTH: <auth-tag>,<N>,<parameters>
are just as parseable in binary as in ASCII. Each parameter is a
byte-string -- with length followed by that many bytes.
>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
>
Should I assume that you are an advocate of S-expressions?
>
>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.
Unless I misunderstand you, this gets into the non-chain certificate
structure addressed by PolicyMaker [BFL]. Have you read that paper?
- Carl
+------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+------------------------------------------------------------------+
Follow-Ups: