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

Re: SPKI Draft Comments

Tony,

        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
even now.



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
encoding.

>(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.

>
>SUGGESTION
>
>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
>    BEGIN-BINDING:
>    SUBJECT:
>    ...
>    EXPIRES:
>    AUTH: <auth-name>
>    BEGIN:
>     <large custom auth>
>    END:
>    END-BINDING:
>    BEGIN:
>     <just about anything>
>    END:
>    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,
>
>    BEGIN:
>    ISSUER:       <key-hash>
>    CERTIFICATE:  <hash-alg>, <body-hash-of-some-certificate>
>    VALID-AS-OF:  <current date>
>    END:
>    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.

Sounds good.

>
>(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

+------------------------------------------------------------------+
|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        |
+------------------------------------------------------------------+