RE: SACRED's vs. credentials' protection requirements [Was: RE: I -D ACTION:draft-ietf-sacred-reqs-00.txt]

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

Stephen wrote, excerpting: 

> [snip]
> > This seems reasonable in principle, but should temper later 
> discussions
> > about how any MUST-implement protection requirement should 
> be framed for
> > purposes of conformant interoperability.  Given an environment where
> > credentials are themselves strongly protected, it could be a strong
> > deterrent to SACRED adoption if the price of admission were 
> deployment of
> > additional infrastructure to support an additional layer of 
> key management
> > which wasn't strictly necessary from a security perspective.
> [snip]
> 
> You're right that there will be cases where using whatever ends up as 
> the standards track SACRED protocol will require overhead that isn't 
> actually useful in the context of a particularly "strong" credential 
> format. 
> 
> However, I think that in order to get an interoperable protocol that 
> allows one to meet the overall charter we'll probably have to mandate 
> that overhead, since we certainly will have to pick some credential 
> format, and I'd be very surprised if that format is likely to be safe 
> to use without the additional overhead.
> 
> Bit fuzzy I know, but I hope you get what I mean. 
> 

Protection quality may be separate from credential format; in general,
interoperability may require not only that a common format be selected but
also that a common protection mode. A format could simply specify encryption
with a key, independent of whether or not that key was password-derived.
PKCS #12, as another example, specifies both password-based and public-key
privacy and integrity modes.  Have we established a working premise for the
level (if any) of protection to be assumed in SACRED-transported credential
objects before they're placed in SACRED hands?

--jl