Bob Blakley's workitems from 9/18 con-call

[George Robert Blakley III <blakley@us.tivoli.com>]

All,

Here are my workitems (and one of Hal's).  Note that the text here is
slightly improved (e.g. correct
grammar, complete  sentences, etc...) from the version in the Powerpoint
slides I sent some time ago.

>[Action - Bob B & Marlena]: <Subject> in Core doc to correspond to
Artifact

Marlena and I will report status by next Mon. (24 Sept.)

>[Action - Bob B.]: Return of not current valid assertions to RP (e.g. post
>dated)

I propose adding the following text to the specification to clarify this
issue:

"A Requesting party SHOULD verify the validity of each assertion returned
in response to its request to an authority.  Authorities MAY return expired
expressions.  Authorities MAY return assertions which are not yet valid
(but
which will be valid during an interval which begins at some future time).

A Relying party SHOULD verify the validity of each assertion it receives
before relying upon them.  Senders MAY transmit expired assertions to
relying
parties.  Senders MAY transmit to relying parties assertions which are not
yet valid (but which will be valid during an interval which begins at some
future time)."

>[Action - Hal & Bob B]: Artifacts are bearer instruments, Assertions are
not

I agree with Hal that this issue is closed.

>[Action - Hal]: to write scenarios (and / or provide definitions) for how
>NameIdentifier is used (e.g., when it is in SubjectConfirmation to
identify
>an assertion vs. when it is used to represent the assertion referent)

Here's my text on this issue, which Hal and I have revised and agreed upon:

"Our assertions and requests contain two classes of information about
subjects:

1. Subject Designation information:

This designates the subject to whom the statements in an assertion refer,
or about whom an assertion is requested.

The semantics of Subject Designation information are:

* Subject Designation elements used both in assertions and in queries:

     - Subject/NameIdentifier: designates the name of the subject to whom
the statements in the assertion
       refer, or about whom the query requests an assertion.

     - Subject/AssertionSpecifier: designates another assertion, which in
turn designates the subject to whom
       the statements in the present assertion refer, or about whom the
query requests an assertion.

* Subject Designation elements used only in queries

     - Artifact: A value which is targeted at an assertion issuer.  An
artifact is understood by the issuer
       to which it is targeted to designate a particular subject  (or even
a particular pre-existing assertion).
       However, an artifact conveys no information about any subject or
assertion to any party except the
       issuer to which it is targeted.

2. Subject Confirmation information:

This designates a method which a relying party may use to confirm that an
assertion it has received refers to
the "correct" subject.  Subject Confirmation information is used to counter
specific threats in particular binding
environments.

SubjectConfirmation should not be a subordinate in the schema to the
Subject element (because it is used to
confirm the value of this element; it should appear at the same level of
the schema as the element whose value
it confirms).

The semantics of SubjectConfirmation are:

* When SubjectConfirmation appears in an Assertion:

     The SubjectConfirmation element does not designate ANY subject; it
designates a mechanism which
     confirms the correctness of the value found in a Subject Designation
element.

     SubjectConfirmation includes:

          - the SubjectConfirmation method

          the SubjectConfirmation method designates a mechanism by the use
of which a relying
          party may satisfy itself that the assertion it has received
designates the "correct" subject.

          There are currently four values for SubjectConfirmation method:

               1. Bearer (no subject confirmation will be done by the
relying party)
               2. HolderOfKey (the relying party will verify that the
sender is able to
                    apply the private key corresponding to the public key
in the
                    SubjectConfirmation/ds:KeyInfo element).
               3. ChallengeProtocol (the relying party will require the
sender to
                    respond correctly to a challenge by executing the
protocol
                    named.  Any data needed by the relying party as input
to
                    the challenge will be included in the
SubjectConfirmation data
                    element).
                    NOTE: Do we have an element which specifies the NAME
                    of the specific challenge protocol to be used by the
relying
                    party?  I don't think so!!
               4. SenderVouches (the relying party will rely upon the
sender's
                    assertion that the correct subject has been
designated).

          - SubjectConfirmation data

          SubjectConfirmation data is used by the relying party when
executing the mechanism
          which SubjectConfirmation method designates, in order to confirm
the correctness of the
          subject designated  in the Subject Designation element.

          If the SubjectConfirmation method is Bearer, no Subject
Confirmation data will be required
          or provided.

          If the SubjectConfirmation method is HolderOfKey,
SubjectConfirmation data (a public key
          belonging to the subject, who may or may not be the sender) will
be provided in the
          SubjectConfirmation/ds:KeyInfo element.  NOTE: Hal believes that
we should also permit
          specification of the NAME of a subject, which would permit the
relying party to retrieve a
          Public-Key Certificate containing the public key to be used for
SubjectConfirmation.  I do not
          believe that we currently have the correct data structure for
this in the schema.

          If the SubjectConfirmation method is ChallengeProtocol,
SubjectConfirmation data will be
          provided in the SubjectConfirmation/ConfirmationData element.
The relying party will need
          to know how to run the specified ChallengeProtocol, and will need
to know when and how
          to use the data provided in the
SubjectConfirmation/ConfirmationData element.

          If the SubjectConfirmation method is SenderVouches,
SubjectConfirmation data (a public
          key belonging to the sender) will be provided in the
SubjectConfirmation/ds:KeyInfo element.

* When SubjectConfirmation appears in a Query

     SubjectConfirmation includes:

          - the SubjectConfirmation method

          The SubjectConfirmation method instructs the assertion issuer to
whom the query is
          directed to protect the Subject Designation information in the
assertion it returns using
          the specified SubjectConfirmation method.

          Requesters should choose a SubjectConfirmation method which will
protect the
          assertion against the threats anticipated in the environment in
which it will be used.
          Authors of bindings and profiles should choose
SubjectConfirmation methods
          appropriate to the protocol environments they are profiling."

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.