RE: Further SACRED requirements comments

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

Al, all, re:

>
> 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."
> >
> 
> AWA:  Okay, I'm not exactly sure what you mean by the new 
> clause "...though 
> not to processing within the protocol's peers..."  Is your 
> intent to convey 
> that the entities that execute the SCACRE protocol in 
> question might also 
> be expected to process the credential at some point, or is 
> there some other 
> point that I'm missing?

I was trying to draw out the point that, while a credential format may be
opaque to the protocol per se, it still needs to be recognized and processed
within the end entities.  This may be stating the obvious, but (mindful also
of some discussion at the San Diego session about distinctions between
SACRED protocol requirements vs. end-entity requirements), I thought it
might be a clarifying point to add here.

> 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)?
>
>
> AWA:  Well, my intent was that the actual credential itself 
> SHOULD/MUST 
> have been (signed/MACed/...), and that e.g. signature on the original 
> object meets these requirements.  These were not intended to be 
> requirements that the entities executing the protocol provide such 
> protection for the credential while in transit.  Why, you might ask? 
> Because to me it seems more important that the original 
> object be protected 
> from original "creation" point until delivered to the user 
> than merely 
> protected in transit.  E.g., the fact that a key was 
> transferred over a TLS 
> session is nice, but it doesn't say anything about what 
> happened to that 
> key PRIOR to the fact of it being transferred, while imposing the 
> requirements on the original object does say something powerful.
> 
> That's my .02, but we welcome comments from others on this issue.

I fully agree.  I think that the authenticity and integrity protection
spanning from credential generation to usage, at the level of the credential
object, is of primary importance (even though not strictly a part of the
SACRED protocol); applying the same services at the connection level offers
incremental value but doesn't replace the benefits of object-level
protection.  It seems like a classic end-to-end security argument; if it's
possible to abstract away trust in intermediaries, it's usually good to do
so. 

--jl