Luther,
> First, concerning point [2], it seems that the IPR statement at
>
> https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=821
>
> covers this draft. Or do we need to update this for each version of a
draft?
It looks like that disclosure covers this draft, but the IETF IPR
disclosure engine didn't find that disclosure when I asked it about
about draft-martin-ibcs-03 - I think I need to file a bug report ;-).
In addition, some indication of where this draft stands wrt Certicom's
patents would be very useful.
> Next, regarding point [3], the algorithms described in this draft are
> public-key algorithms and are definitely not stream ciphers.
I stand behind point [3], here's a longer explanation and example:
At least Section 8.4 and 8.5 perform encryption and decryption by
XOR-ing a keystream with the plaintext or ciphertext (Sections
5.4 and 5.5 appear to do likewise, but there are potential mistakes
in those sections that make this somewhat unclear). While "stream
cipher" may not be a precise term for these constructs, they are
at least a stream-cipher-like operating mode for the public key
algorithms. In particular, they are subject to <key,IV> reuse
concerns that apply to stream ciphers.
Specifically, for section 8.4, the actual encryption step for the
message m is:
y = HashStream(|m|, h') XOR m
where h' does not depend on m, so if the same s (effectively an IV)
is ever used twice with the same identity and public parameters for
different messages that have the same length (e.g., m1 and m2), the
HashStream element will be the same, so one can obtain the XOR of
the plaintext messages by XORing the corresponding ciphertexts, i.e.:
y1 XOR y2 = m1 XOR m2
This is usually considered undesirable, as it tends to leak information
about m1 and m2. At a minimum, this needs to be discussed in the
security considerations section, even if the countermeasures to
prevent this from happening are left to other documents that apply
these algorithms to particular contexts.
> Are architectural issues, like the restrictions on letting arbitrary
> clients decrypt on behalf of an arbitrary identity, more suitable for
> other documents? After all, this document just describes two
> cryptographic algorithms. Are issues surrounding their applications
> better described elsewhere?
Yes and no. Let me start with an apology. The following text from
my review is not correct:
-> It is *very* important to understand that the ability to encrypt
-> or decrypt on behalf of an identity is not proof of that identity,
-> and hence the mechanisms described in this draft MUST NOT be used
-> for authentication purposes, and any identity used with these
-> mechanisms MUST be authenticated or verified by other means.
With a suitably configured key server including proper use of
authentication with key server clients, proof of possession of
the private key for an identity could be used as proof of that
identity (i.e., authentication), but the configuration restrictions
are important. In any case, the above text is wrong as written,
and I apologize for that mistake.
At the very least, the draft needs an architectural diagram showing
the key server and the clients showing which keys flow where for
at least one example - that would have saved me from this mistake,
and the fact that I made it is a backhanded indication that such
a diagram and associated discussion is needed. I think that
discussion also needs to bring out the dependence on the key
server and authentication to the key server in restricting
availability of private keys to their corresponding identities
if one intends to use them for authentication.
> We will take a closer look at the other comments soon.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
