[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPKI Draft Comments
sorry to take so long to get back to you. I've been out of town and
I'm in the middle of a crunch at work so I can't spend much time on SPKI
At 12:49 PM 8/22/96 -0700, Tony Bartoletti wrote:
>QUESTION (4.3 Boundary lines BEGIN and END)
My intention was that wherever a string is specified, there needs to be a
count for it even if it's 0.
>If this is the case, either 4.3 (or the section on binary format) should
>state that "In binary coding, all BEGIN and END tags are followed by the
>two-byte (short) length of the optional name or comment, even if this is
>zero (no name)."
Thanks for the suggestion.
>MOTIVATION for BEGIN-END pairs:
>I agree with the need, and the restriction on nesting. However, the
>current description seems only vaguely motivated. 4.3 states that they
>are to be used for
> "Any multiple-line object, such as a certificate body or a signature".
>(Is a 200 byte number, displayed as base64 text (foreinstance) considered
>to be a multi-line object? In binary form, the BEGIN-END tags for such
>become superfluous, as the byte-string is preceded by its length, and so
>not broken into "lines".)
No -- I shouldn't have used "line" here. It's really multi-field, since
RFC822 rules take care of continuation lines as you might find with base64
>(Conveniently, the only non-cert-body element mentioned is signature,
>which of course cannot be in the cert-body.) The BEGIN-END device is
>made to sound general-purpose, and yet is tightly coupled to the form
>of signature by (7.1 Signature Format) where, for signatures lacking
>the optional body-hash parameter, 7.1 states:
> "the SIGNATURE is taken to apply to the preceding BEGIN-END block."
>This *sounds* as if signatures which *do* use a body-hash do not need to
>be signatures over "the preceding BEGIN-END block". But then what is the
>signature to be tested against? The cert-body requires a BEGIN-END
>delimitation in any case, so what is the "optional body-hash" for?
The body hash, following a suggestion by Greg Rose, identifies the signed
object in a way that's convenient for lookup and cryptographically secure at
the same time.
>The fact that (multi-line) cert-bodies require enclosing BEGIN-END pairs,
>and that such pairs do not nest, means that cert-bodies are precluded from
>containing any multi-line element, such as a 200 byte custom AUTH parameter
>(I know I'm reaching here).
How do you fall on the question of S-expressions?
I know I'm inviting trouble by bringing this up here, but there is an
elegance to S-expressions (ala SDSI) which forestalls such questions.
OTOH, S-expressions make it difficult to refer to previously transmitted
elements while the hash-linkage makes that the application's option.
Thinking as an implementor, especially if I'm limited in my execution
environment (e.g. a smart card), I would want all nesting unrolled the way
the pointer-via-hash does it.
>I would have preferred, in addition to the generic BEGIN-END tags,
>that there be defined a pair of explicit "BEGIN-BINDING, END-BINDING"
>tags, to unequivocally delimit the quantity whose hash has been signed.
>Such a device would avoid the most obvious irritation at the no-nesting
>restriction. Between the BINDINGs, and thereafter, arbitrary BEGIN-END
>pairs could appear (no nesting allowed.) Example:
> COMMENT: mycomment
> AUTH: <auth-name>
> <large custom auth>
> <just about anything>
> SIGNATURE: <over BEGIN-BINDING, END-BINDING block>
I had envisioned BEGIN/END enclosing anything signed.
There's no BEGIN/END for large custom <auth>.
>(5.1.1 Other Certificate) MOTIVATION
>My idea of a "certificate affirmation" (reiterated short certificate)
>would have the issuer send, for a previously issued full certificate,
> ISSUER: <key-hash>
> CERTIFICATE: <hash-alg>, <body-hash-of-some-certificate>
> VALID-AS-OF: <current date>
> SIGNATURE: <of issuer over the above BEGIN-END block>
>as a way of indicating that the status of the "named" certificate
>(ID'd by body-hash) has not changed. VALID-AS-OF <current date>
>is needed to thwart playback attacks.
>(7.3 Key Format) MOTIVATION
>This is not a question about the format per-se, but the draft showed
>scant occasion to employ this field. Foreinstance, the SUBJECT field
>and ISSUER field both specify a key-hash. (4.1.1 SUBJECT) states:
>"The actual key is assumed to be in the verifier's possession although
>a given protocol might call for transmitting that key during the same
>communication that carries the certificate using it." That is, during
>the same communication, but not as a part of the certificate itself,
>hence not an occasion to employ the "KEY" tag. Where is it envisioned
>that the KEY tag is to be used? (I understand that by 2.2, the area
>of key acquisition is not covered.)
The KEY tag was to be used outside a cert body -- to communicate a key from
supplicant to verifier. It's referenced by hash inside the body.
>Enough for now. Overall, I generally found the draft to be clean, clear
>and concise. Looking forward to that bin-to-text, text-to-bin code.
I wish I had gotten it done by now. I'm tempted to do both RFC822 and
S-expression ASCII versions, but at the rate I'm going, it'll be someone
else's code that appears first.
|Carl M. Ellison email@example.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 |