Re: Denis' suggested IDUP change
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Denis' suggested IDUP change



Bob,

Thank you for your comment.

> >In commercial and governmental environments the role or position
> >within the organisation of the sender of a document is a crucial
> >information (e.g., when verifying a document using the
> >IDUP_EV_SingleBuffer_Verify call, we may currently know that Mr. Smith
> >sent it ; it makes a difference if that routine call may also
> >indicate that Mr. Smith is the Sales Director from Delta Corporation.

> >It would therefore be convenient to be able to carry this datum as part
> >of the originator's information.

> I think this is a good proposal and should be adopted (though *
> the time is late...), perhaps with two small amendments
 
> >The Originator_Information parameter bundle defined in section
> >2.3.3.2. of draft-ietf-cat-idup-gss-10.txt (page 25) could be modified
> >in order to include the originator's role, where the role would be
> >defined as :

> >o  Originator_Role PARAMETER BUNDLE
> >   o  domain_name       PRINTABLE NAME OPTIONAL,
 
> I don't understand why this is a PRINTABLE NAME while the token generator
> name is an INTERNAL NAME.  It seems more logical to me to use the following
> declaration instead:
 
> o  Originator_Role PARAMETER BUNDLE
> o  domain_name        INTERNAL NAME OPTIONAL,

I agree.

> >   o  role              PRINTABLE STRING
 
> The other modification I'd suggest is some text suggesting whether 
> the Originator_Role parameter is authenticated or not; in the 
> example Denis gave it was derived from a certificate extension, 
> which suggests that it is authentic information.  I can imagine 
> systems in which it is only asserted by the sender and not
> authenticated to the receiver.  It ought to be made clear in the 
> text whether this parameter, if present, "must" or "may" be 
> authenticated; this will help implementers understand their
> obligations in supporting this feature.

I share your concern. However you don't make a proposal :-)

I would figure out that some people would like to support either an
authenticated role or an asserted role. In practice this would mean to
support two optional parameters.

This would lead to a structure like this:

 o  Originator_Role PARAMETER BUNDLE
 o  domain_name        INTERNAL NAME OPTIONAL,
 o  auth_role          PRINTABLE STRING OPTIONAL,
 o  assert_role        PRINTABLE STRING OPTIONAL,

Would this be O.K. ?

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:Denis.Pinkas at bull.net
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.