Comments on draft-arsenault-sacred-reqs-00.txt

[Graham Klyne <GK@xxxxxxxxxxxxxx>]

Folks,

I offer the following observations for your consideration.  They consist 
mostly of presentational nits.


General:

I noticed a few instances of a non-ASCII character being used where (I 
assume) an apostrophe (') was intended.  E.g. "Mimi?s" in section 2.1.


Abstract:

I think it would be helpful for the first paragraph to mention mobility of 
credentials in some way.  E.g.

   This document describes requirements to be placed on Securely
   Available Credentials (sacred) mobility protocols.


Section 1, final para:

I have found that the RFC2119 keywords, designed as they are for describing 
protocols, don't always work well when describing _requirements_ on 
protocols.  For example, I'm not sure exactly what is meant by requirements 
G9, S4:  are these saying the "protocol specification MAY define...", or 
that the protocol must be specified in a way such that "protocol 
implementations MAY..."?

An alternative approach to describing protocol requirements levels can be 
found in RFC 2542, section 1.1.


Section 1.1, 2nd para:

When reading this, it occurred to me that having Mimi keep credentials on 
her computer was also not really very secure.  I'm not sure if it's worth 
saying anything about this -- maybe properly managed mobile credentials 
would be _more_ secure.  Or, to put it another way, is it possible that the 
sacred framework would help to protect credentials on a single system 
(regarding the transfer between long-term storage and immediate use as a 
kind of movement of credentials)?


Section 1.2:

How does the secure transfer of credentials between devices differ from the 
secure transfer of *any* sensitive information?  (A clear answer to that 
question might help to convey the essence of this effort.)


Section 2:

Starting to read this, it seems to consist of background material as much 
as requirements.  I would suggest that the pedagogical background material 
(which I think is very useful) be separated from the specific requirements.


Section 2.1, page 5, final para (bullet 2):

You say the credential server "may" have to be trusted...  Is this strong 
enough?  Otherwise, why not use any old web server?


Section 2.1, page 6, 1st 2 paras:

I found the first paragraph confusing, and the second paragraph to be 
rather laboured (though it did clear up my confusion).  In general, I think 
the idea of a "direct" transfer as described is already implicit in the way 
Internet applications and protocols work.  Thus, I think the two paragraphs 
could be replaced by:

   Thus, some users may prefer a different class of solution, in which
   credentials are transferred directly from one device to another
   (i.e. having no intermediary element that processes or has any 
understanding
   of the credentials).


Section 2.2, requirement F3:

I think the "which" here should be "that".


Section 2.4, editorial comment:

IMXP might be a candidate, suitable to a range of operating environments.
<draft-mrose-imxp-core-01.txt>


Section 3.1, requirement G3:

Is SHOULD strong enough?  I'd have thought this is a MUST.


Section 3.1, requirement G6:

is this "MUST support the use of ..." or "MUST support the transfer of ..."


Section 3.1, requirement G9:
Section 3.2, requirement S4:

I'm not sure what MAY means in these contexts (see earlier comment)


Section 3.1, requirement G10:

There's more to full I18N than charset use.  Also language tagging for 
human readable text.


Section 3.1, requirement G12:

Privacy from whom?  For example, it seems to me the client must be 
identified to somebody if credentials are transferred only to properly 
authorized recipients.


Section 4, item "Vulnerabilities:"

Should the framework specification not include some kind of trust model?

--

That's all.

#g
------------
Graham Klyne
(GK@xxxxxxx)