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

SPKI Draft Comments

Carl,

Having read the draft document several times, and attempting to create
examples, I have some (naive) questions and suggestions (not by any means
an exhaustive list:-)

QUESTION (4.3 Boundary lines BEGIN and END)

In binary format, the sequence of bytes [1][2][3]... would seem to
code equivalently for

    BEGIN:
    SUBJECT:  RSA,...
and
    BEGIN: <515-byte-optional-string-name-on-the-BEGIN-line>

Granted that this is a ludicrous example, but I fear I do not quite
understand the transformation between text and binary forms here.
The only way out that makes sense to me would be to encode the former
as [1][0][0][2][3]..., that is

    BEGIN: <zero-length optional name or comment string>
    SUBJECT: RSA,...

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)."

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".)

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

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>


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


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

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.

Thanks for the consideration.

___TONY___


Tony Bartoletti                                             LL
SPI Project Leader                                       LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL