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

From: "Linn, John" <[email-masked]>
Date: Fri, 1 Dec 2000 11:34:49 -0500

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

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 8 Dec 2000 16:04:27 +0100 (W. Europe Standard Time)

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

-- Magnus

> themselves, but I'm unsure where we currently stand on this question. 

-- Magnus
Magnus Nystrom
RSA Security