Further SACRED requirements comments

["Linn, John" <jlinn@xxxxxxxxxxxxxxx>]

> I'd like to offer a few further comments about the SACRED requirements
> document, over and beyond those raised in prior list discussion and noted
> in the San Diego discussion minutes.  
> 
> Regarding treatment of the serverless case, it seems (a) that it's
> suitably motivated within the requirements document but (b) that there's
> not as much current momentum or constituency to carry it forward into
> lower-level documents.  If this situation persists, I suggest keeping the
> requirements-level discussion as is but narrowing the framework scope to
> "Securely Available Credentials - Framework with Credential Servers" or
> some such.  This would allow the serverless case to be pursued in a
> parallel framework document at a later date. 
> 
> In the requirements document, #F4 might usefully be restated "The details
> of the actual credential type or format MUST be opaque to the protocol,
> though not to processing within the protocol's peers. The protocol MUST
> NOT depend on the internal structure of any credential type or format."
> 
> If #G3 and #G4 (authentication and integrity protection for transferred
> credential data) are necessarily to be accomplished by the protocol,
> rather than within the credential objects themselves, suggest rewording to
> "The protocol <SHOULD|MUST> provide ...", consistent with subsequent
> requirements.  More broadly, just what does it mean to authenticate a
> credential, vs. authenticating a protocol peer?  In the case of a
> download, e.g., the originator of the credential may well have signed the
> credential object at some point in the past, enabling its authenticity to
> be verified, but won't generally be its source from the perspective of the
> transfer protocol.  Does the original object signing satisfy the intended
> requirement, or is this intended to concern connection-level
> authentication of the credential provider (e.g., via TLS)?
> 
> Re #G7, it seems somewhat strange to specify support for a particular
> credential format (an opaque object transported by the protocol) under the
> heading of a protocol conformance requirement; by analogy, it would be as
> if conformance to the TCP specification required support for HTTP (or for
> any other specific protocol which layers over TCP).  This may be an
> interoperability requirement, but it seems outside the scope of protocol
> conformance. 
> 
> Requirements #S6 and #S7 mesh a bit oddly to me.  I can see value in
> authenticating the server to the client for download, primarily as an aid
> to determining that the most current version of a credential is being
> obtained.  (I'd expect that a wholly invalid credential would probably be
> detected based on integrity facilities within the credential format.)  I'm
> not sure that this is necessarily a MUST for all cases, but don't think
> that its value depends on whether or not the server authentication can be
> verified before the credential crosses the wire.  If, e.g., a
> correctly-formed credential carried data which could be used as one of the
> inputs applied to cross-check the server's authenticity after the fact,
> this could be OK (as long as the client didn't overwrite any existing
> credentials before these steps were performed).  Would it be reasonable to
> place server authentication upon download as a general SHOULD, independent
> of whether or not that authentication occurs prior to the download
> operation?
> 
> --jl
> 
>