[Ietf-keyprov] FW: Updated provisioning doc (RE: OATH Provisioning call Jul 31: minutes)

[Shuh Chang]

-----Original Message-----
From: Shuh Chang [mailto:shuh.chang at gemalto.com]
Sent: Monday, September 18, 2006 11:36 PM
To: Jim Spring; Pei, Mingliang; Kevin Lewis; svaeth at diversinet.com;
Hallam-Baker, Phillip; Bajaj, Siddharth; Susan Cannon;
jon.martinsson at portwise.com; Salah Machani; Chen, Hseuping; Jeffrey
Bohren; Philip Hoyer; Ron LaPedis; Robert Zuccherato;
ietf-keyprov at safehaus.org
Subject: RE: Updated provisioning doc (RE: OATH Provisioning call Jul
31: minutes)


Hi All,

As promised in today's OATH/DSKPP conf call, I am sending you the comments
that I had for the latest DSKPP specification. I have generalized a lot of
comments that I originally had, skipped the ones that Kevin already
identified, and summarized them into a smaller list in the attached word
document, dskpp_change_requests.doc.

I was originally thinking about taking Kevin's latest version, and adding my
comments on top of it. However, some of my comments may reqiure some
discussions and clarification before major changes/revisions are made, I
decided to simply put them in a list of comments as we did for the PSKC
specification so that we can all discuss and agree on what will be the best
for all.

As for Jim's comments, although my comment on the overall oath: XML
namespace and the individual oath-xxx: namespaces may address some of his
concern, it doesn't cover them all. I agree with Jim that XML schema is one
of the implementation means that may not be adequate for a design spec. On
the other hand, I think XML schema is now becoming an universal data
definition language. It might be difficult to define the kinds of OATH data
types and command structures without XML, unless we can find an alternative
to represent the data structures of interest. Of course an ERD similar to
what Salah did for PSKC may help. However, the XML is still the best way of
representing the data definitions at the present time, I think.

As for the transport layer, my impression from today's conf call was that
Ming will rewirte some of the sections to better clarify the points. Is that
correct?

Ming, if you need some extra hand in incorporating the comments that I had
(after we all have agreed), please let me know and I'd be glad to help out.
Thanks.

Regards,
Shuh


-----Original Message-----
From: Jim Spring [mailto:jspring at ironkey.com]
Sent: Monday, September 18, 2006 10:33 AM
To: Pei, Mingliang
Cc: Kevin Lewis; svaeth at diversinet.com; Hallam-Baker, Phillip; Bajaj,
Siddharth; Susan Cannon; jon.martinsson at portwise.com; Salah Machani;
Chen, Hseuping; Jeffrey Bohren; Philip Hoyer; Ron LaPedis; Robert
Zuccherato; Shuh Chang
Subject: Re: Updated provisioning doc (RE: OATH Provisioning call Jul
31: minutes)


Sorry for the delay in getting the review notes back.  I agree with a
lot of the grammar and other edits that Kevin pointed out in his
thorough vetting of the document.  Some more general comments:

1.  The document appears to blend the definition of a protocol with
implementation suggestions, specifically around the transport layer.
This is further confused by mixing parts of the discussion within the
protocol definition section (3) and then later in section (6).  This
needs to be cleaned up and specifically issues around the provisioning
protocol and transport layer security addressed need their own clear
sections.  Potentially discuss the transport layer security issue first
and then indicate potential solutions (GetAuthNonce/etc) within the
protocol flow.

2.  There is a whole lot of the document that is left up to reading the
XML Schema to determine what options are present.  For instance, what
ciphers are allowed, etc.  Reading and parsing XML is not the easiest
thing to do when reading a technical document.  Furthermore, if you look
at many IETF documents the discussion of the various parts of a protocol
layout the individual options at each point and then contain an appendix
summarizing the overall protocol options and how things are encoded.

3.  It is not clear to me that a man in the middle attack still does
exist with the GetAuthNonce/etc.  I need to review this some more.


In general, I think it is a good start.  However, there needs to be
better organization that is consistent with other IETF documents with
less reliance on having to read the XML.

-jim spring
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dskpp_change_requests.doc
Type: application/msword
Size: 37888 bytes
Desc: not available
Url : http://www.safehaus.org/pipermail/ietf-keyprov/attachments/20060918/1ef249e7/dskpp_change_requests-0001.doc