Hi Joel,
Many thanks for your review. Some notes inline:
I am a bit under the weather, and so if I am incoherent, please feel
free to say so. Thanks.
On 3/17/2008 1:47 PM, Joel M. Halpern wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: Specification for the Derivation of Root Keys from an Extended
Master Session Key (EMSK)
Reviewer: Joel M. Halpern
Review Date: 17-March-2008
IETF LC End Date: 17-March-2008?
IESG Telechat date: N/A
Summary: This document appears ready for publication.
Comments:
While there has been much discussion on the IETF list of the
references to "applications" in this document, I have chosen not to
comment on that. It seems to me that the relevant statement is that
specific usages are out of scope for this document.
The one thing that bothers me a little is the intended status of
this document. Given that the EMSK is entirely inside a system, and
that therefore the actual generation process is internal to that system,
I am not sure that a registry tied to the specifics of the generation
mechanism, is appropriate. A lot of this document is of the form "if
you don't define it some other way, do this." While very useful text,
it actually doesn't seem to affect on-the-wire interoperability. So I
wonder if this whole document is more informational than "proposed
standard?" I'm not sure on this, but the containment property did
strike me reading the document.
The peer and the server need to arrive at the same derivations. The
keynames derived as specified in this document would be used in
protocols specified elsewhere to refer to the keys derived independently
at both ends. So, whereas there are no "on the wire" packet formats in
this document, other documents will put information derived as specified
in this document in their packets.
Minor:
While I would guess that the usage is actually the normal usage, the
definitions of Usage Specific Root Key, Domain Specific Root Key and Key
Management Domain are somewhat confusing for the outside reader.
Specifically, the Key Management Domain is defined as being the scope of
a given root key. This leads the reader to conclude that any root key
is inherently domain specific, because it defines a domain. So how can
one have a special kind of "Domain Specific Root Key" that is
"restricted to use in a specific key management domain." At a guess it
is the difference between a domain defined by the key and a key defined
to fit an existing domain. But I hate guessing when it comes to RFCs.
Given that the document later defines the domain for DSRK in terms of
domain names, "adding "separately defined" or even "defined by a domain
name" to the DSRK definition would address this.
The last of the requirements (about separation of domain keys and
usage keys and avoiding label collision) requires material later in the
document in order to be understood. A forward reference would be a good
idea, indicating where the domain name and usage key label are described.
It looks like some clarification is in order in the text.
regards,
Lakshminath
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf