Re: Registry Security Spec Version 003

[christopher ferris <chris.ferris@east.sun.com>]

Krishna,

Some comments on your proposal.

sect 1.1 - please don't confuse authentication and authorization.
They are *very* different animals.

sect 1.2 - typo: voracity s/b veracity.
the last sentence is also a bit confusing. I would prefer something
such as: Registry content MUST be cryptocraphically bound to and
signed by the private key of the SO so that it can be verified
by any party with access to the SO's public key.

sect 1.3 - I would reserve this for a possible future. It isn't
clear to me that this is a requirement at this time.

sect 1.4 - change shoulds to SHALLs
Also, I would prefer that this section be placed after 1.1. I would
also suggest that Identification be elevated to its own section.
Identification is needed to enable authorization. Authentication is
the act of verifying the credentials presented as part of the
act of claiming an identity.
Authorization is the act of verifying that a requested action is
granted by one (or more) of the privileges associated with a given 
identity.
Granting of privileges needs to be defined somewhere. Possibly
some manner of "root" or "super-user" identity is granted the
privilege to grant privileges, etc.

sect 3.2 - if you assume that TR&P MS has responsibility for signing
and verifying the signed header and payload, then you are limiting
the RegRep security to use of XMLDSIG... None of the MIME-based
security schemes can sign both the header and payload.

Note also that since the payload object(s) need to be signed
and retrieved with the signature, that you probably want to
SEPARATELY sign the payload such that it is part of the
object being signed. e.g. if I submit a CPP to the registry,
then it should be a signed CPP object that is stored and
retrieved from the registry. Using a combined signed header
and payload to accomplish what you suggest would require
some pre-assembly on the part of the regrep to extract the 
signature from the message and associate it with the object
being stored, etc.

sect 3.4
The FIRST step is identification, not authentication. Second
step is collection of credentials that substantiate the
claimed identity. The third step is verification of the
credentials resulting in either an authenticated or unauthenticated
identity.

General comments:
- I should think that what you should do is to characterize
the regrep process collaboration using the BPM, and characterize
the security constraints using the same set of attributes
as are provided by the BPM.
- secondly, I think that you should re-think the whole aspect
of signing. If a payload object(s) must be associated with a 
signature, then you will really need to have this handled by the
application and not have the signature part of the header...

Cheers,

Chris


Krishna Sankar wrote:
> 
> Hi all,
> 
>         Here is the next version of the Registry Security Specification. I have
> included the changes as per our many discussions with various folks. Please
> read thru and express your ideas.
> 
>         The document is still in it's infancy. One question I have is where would
> this fit in ? Should it be consumed by the registry spec ? If so which one ?
> What about the security requirements section ? Does it have a home ? Or do
> we let this document stand as a separate document ? Is there a consolidated
> ebXML security specifications which this document could be part of ? If not,
> may be we should start one - which talks about security Architecturally and
> gives tactical and operational details as well.
> 
>         cheers
> 
>   ------------------------------------------------------------------------
>                                     Name: ebXML RegRep Security-003.doc
>    ebXML RegRep Security-003.doc    Type: Winword File (application/msword)
>                                 Encoding: BASE64
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard