-----Original Message-----
From: Leif Johansson [mailto:leifj(_at_)sunet(_dot_)se]
Sent: Sunday, April 01, 2012 5:59 PM
To: Black, David
Cc: leifj(_at_)nordu(_dot_)net; gen-art(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; turners(_at_)ieca(_dot_)com;
tim(_dot_)polk(_at_)nist(_dot_)gov
Subject: Re: Gen-ART review of draft-johansson-loa-registry-04
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/01/2012 10:57 PM, david(_dot_)black(_at_)emc(_dot_)com wrote:
I am the assigned Gen-ART reviewer for this draft. For background
on Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call
comments you may receive.
Document: draft-johansson-loa-registry-04 Reviewer: David L. Black
Review Date: April 1, 2012 IETF LC End Date: April 3, 2012 IESG
Telechat date: April 12, 2012
This draft establishes an IETF registry of SAML Level of Assurance
(LoA) profiles; it's short and clear, although it does not contain
any initial content for the registry - presumably that will be
supplied after the registry is created via the expert review
registration mechanism established by this draft.
Summary: This draft is on the right track but has open issues,
described in the review.
Major issues: (1) My major open issue concerns the last paragraph
in the Introduction:
Although the registry will contain URIs that reference SAML
Authentication Context Profiles other protocols MAY use such URIs
to represent levels of assurance definitions without relying on
their SAML XML definitions. Use of the registry by protocols other
than SAML or OpenID Connect is encouraged.
While this is good in principle, and one presumes that each
registration of sets of profiles from an existing protocol will be
self-consistent, this text also encourages other (e.g., new)
protocols to draw upon this registry without providing any
guidance. I'm concerned that it's probably possible to make a
serious mess in a new protocol by using an LoA or two from
multiple sets of registered LoAs without paying attention to
whether the resulting collection of LoAs is consistent or coherent
(or even sensible) for use in a single protocol. This concern is
reinforced by the guidance to expert reviewers in Section 4.1,
which effectively conveys a desire to get all of the reasonable LoA
profiles registered here, regardless of source or consistency with
other registered LoA profiles.
I'd like to see some guidance to protocol designers and others for
how to appropriately select multiple LoA profiles from this
registry in a fashion that results in a consistent and (hopefully)
usable collection. For example, it may be a good idea to use (or
start with) a set of related profiles already in use by an existing
protocol in preference to mixing/matching individual profiles from
multiple existing protocols. At some level, this is common sense
advice that the presence of profiles in this registry does not
obviate the need to apply good design judgment, but that does
deserve to be stated.
David,
The type of consistency you look for is extremely difficult to ascertain
and often rely on mapping the underlying policies. However I do see your
point. How about this:
"Protocol designers who want to reference this registry should be aware
that registered LoAs may depend on assumptions that do not carry over
to a new protocol."
Minor issues: (2)
(1) This draft is intended to be an informational RFC, but it uses
RFC 2119 keywords. That's only a good idea in exceptional
circumstances. I suggest removing section 1.1 and replacing upper
case MUST/SHOULD/MAY with their lower case versions or reworded
explanations of rationale. Most of the uses of RFC 2119 keywords
are not protocol requirements, but requirements on IANA,
registrants, and users of the registry for which RFC 2119 keywords
are not appropriate, e.g., see RFC 2119 section 6:
Imperatives of the type defined in this memo must be used with
care and sparingly. In particular, they MUST only be used where it
is actually required for interoperation or to limit behavior which
has potential for causing harm (e.g., limiting retransmisssions)
ok
(2) Section 4
OLD The initial pool of expert and the review criteria are outlined
below. NEW The review criteria are outlined below.
The initial pool of experts is not designated by this draft.
good catch
Nits/editorial comments:
Section 3
OLD The following ABNF productions represent reserved values and
names NEW The reserved element defined by the following ABNF
productions represents a set of reserved values and names
ok
Section 4
The registry is to be operated under the "Designated Expert
Review" policy from RFC5226 [RFC5226] employing a pool of experts
Nope, the actual RFC5226 name of that well-known IANA policy is
Expert Review (or Designated Expert), see section 4.1 of RFC5226.
If that well-known IANA policy isn't what was intended, this is a
serious open issue.
that IANA policy was indeed intended.
Top of p.7 The presense of an entry in the registy MUST NOT be
taken to imply ^ r ---------------------------------------/
Here I actually want normative language. It is quite important that the
registry not be over-interpreted.
Section 7
OLD An implementor of MUST NOT treat the registry as a trust
framework or NEW A protocol implementor MUST NOT treat the registry
as a trust framework or
I actually don't mean protocol implementor here. I mean consumer of the
registry.
The minor issue about RFC 2119 keywords also applies to this text.
This is another case where I think I disagree!
idnits 2.12.13 did not find any nits that need attention.
Thanks, --David
thank you!
Cheers Leif
---------------------------------------------------- David L.
Black, Distinguished Engineer EMC Corporation, 176 South St.,
Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508)
293-7786 david(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978)
394-7754
----------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk94z7cACgkQ8Jx8FtbMZnczSACgtOd/Ltv7PXDMYFkdbDHBeKdB
n7UAoKNkSnBB/ZQZF96gwvKbTnXQq8Nt
=lEQ5
-----END PGP SIGNATURE-----