RE: I-D ACTION:draft-ietf-sacred-framework-00.txt

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

The intent is to include trusted public keys in the credential
and not to assume they already are available.

-- Magnus

On Fri, 1 Dec 2000, Linn, John wrote:

> Mike wrote, excerpting: 
> 
> > [...] 
> > > > - [Section 3.1, 2nd bullet] The requirement for http might be ok, but
> why 
> > > > require TLS. This gets into the argument that you mention in Section
> 6, 
> > > > regarding the (de)coupling of the credential and protocol protections.
> The 
> > > > strong password algorithms of Section 4.2 would not require TLS
> protection, 
> > > > for example. 
> > > 
> > > In this draft, we removed a few restrictions that had been suggested
> earlier -- 
> > > originally HTTP over TLS was the only transport considered and was
> mandantory. 
> > > In this revision HTTP / TLS is not the only possible transport protocol.
> We may 
> > > have to refine the wording in several additional places to makethis more
> clear. 
> > 
> > Note also that it only says "must be able to..." - it does not 
> > require TLS. I agree that the memo requires some clarification in 
> > this respect however, e.g. Section 3.1.1, first item in the list 
> > should probably read something like "..., that is, when TLS is used, 
> > only cipher suites..." 
> > 
> 
> [MJ] I guess that "requiring" and "being able to" aren't that different to
> me. Your rewording sounds fine in any case.  
> 
> I take the intent as requiring support for TLS in the interests of
> interoperability, though without mandating that it must always be active and
> used.  More broadly, though, I believe that there's a dependency that
> warrants some explicit discussion.  In order to validate TLS server-side
> authentication, it's necessary for the verifier to hold a corresponding
> trusted public key. Strong password schemes, in contrast, may not incur this
> dependency in order to establish a trusted channel to a server and therefore
> could enable an entity's trusted keys to be provisioned across that channel.
> 
>  
> Does/should the scope of credential download include transfer of an entity's
> trusted public key(s), or do we assume that they're already available as a
> basis for authenticating credential servers in the course of obtaining
> credentials?  The first paragraph of draft-ietf-sacred-reqs-00.txt's
> Introduction refers to trusted roots as one element within credentials
> themselves, but I'm unsure where we currently stand on this question. 
>  
> --jl 
> 
> 

-- Magnus
Magnus Nystrom
RSA Security