RE: Registry Security Spec Version 003

["Burdett, David" <david.burdett@commerceone.com>]

Krishna

You asked ...

>>>I have asked this question many times - Is the TRP going to be a black
box with regard to applications or will it "communicate" with the layers
above ? If the TRP is a black box, then the registry specification will add
the required stuff for payload signing et al. If not, the registry will
leverage the TRP capabilities. This is still not clear to me, I am sure the
answer is out there somewhere.<<<

The answer to this question depends on whether you are defining:
a) a wire specification with a description of the behavior of the software
at each end, or
b) a software solution that implements the specification defined in a)

I think we are doing the former - the wire specification. More specifically
we are saying the following:
1) You can have a XML Dsig compliant signature in the ebXML header which can
potentially sign anything, and
2) The MIME part that is the payload may be digitally signed using, S/MIME,
PGP/MIME or XML Dsig.

However whether or not software that supports the ebXML specification is
able to sign a payload really is an implementation decision of the software
designer. 

So to answer your question ... "Is the TRP going to be a black box with
regard to applications or will it "communicate" with the layers above ?" The
real answer is it depends on how you build your solution or the features of
the ebXML solution you buy.

So for your spec, I would focus on describing the requirement rather than
the solution to the requirement. For example if you wanted allow the payload
resulting from a reg-rep query to be digitally signed, then I would use
words along the lines of:

>>>"The Payload of the Reg-Rep query MAY be signed using a XML Signature
within the ebXML Header Document, etc...<<<

David

-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Tuesday, December 26, 2000 11:55 AM
To: ebxml-regrep@lists.ebxml.org; Ebxml Transport; Ebxml-Ta-Security
Subject: RE: Registry Security Spec Version 003


Chris,

	Comments embedded.
cheers

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, December 26, 2000 7:24 AM
> To: Krishna Sankar
> Cc: ebxml-regrep@lists.ebxml.org; Ebxml Transport; Ebxml-Ta-Security
> Subject: Re: Registry Security Spec Version 003
>
>
> Krishna,
>
> Some comments on your proposal.
>
> sect 1.1 - please don't confuse authentication and authorization.
> They are *very* different animals.
>
Yep, I am aware of that ;-) I assume you got this impression reading thru
lines 77-79. The lines just say that you need authentication for
authorization. May be they are extraneous, but just brings the idea of
private spaces inside a registry which can be accesses by authenticated
users.

> sect 1.2 - typo: voracity s/b veracity.

Thanks. Will do.

> the last sentence is also a bit confusing. I would prefer something
> such as: Registry content MUST be cryptographically 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.
>

Thinks. I will try to make it clearer.

> 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.

Sections 1 & 2 describe the requirements - WHAT is needed. There is no time
element in Section 1 or 2 - some would be in Phase 1 and some in later
phases. Section 3 is where we talk about what is available in Release 1.
>
> sect 1.4 - change shoulds to SHALLs

Done. Thanks.

> 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.
>

Will add a separate identification section. Again, I am well aware of what
authorization and authentication means ;-). Adding a separate identification
section is a good idea.

> 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.
>

There is no such assumption. I am only looking for the syntax and semantics.
That way we do not have to replicate them in *every* specification.

And again, we will augment whatever is in the TRP spec, with more details in
this section. Hence I added this section - to bring out the leverage points
and the additional work required.

I have asked this question many times - Is the TRP going to be a black box
with regard to applications or will it "communicate" with the layers above ?
If the TRP is a black box, then the registry specification will add the
required stuff for payload signing et al. If not, the registry will leverage
the TRP capabilities. This is still not clear to me, I am sure the answer is
out there somewhere.

> 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.
>

You assume a COMBINED header and payload signature. There is no such intent
and not mentioned in the registry specs. (I have written the assumptions
later in this e-mail)

> 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.
>
Thanks. I will separate the identification part.

> 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...
>

Looks like there is some confusion - I will read the specs thru and make
sure it is clear on this. Here is my current understanding.

a)	The header and payload will be signed separately. And the TRP will
have
the semantics and syntax.

b)	Registry will use the header signature for identification and
authentication

c)	Registry will use the payload signature for integrity. The registry
will
store it and will pass it on to the users of the content.

d)	The header and payload can be signed using different algorithms. I
think
the header is limited to XMLDSig and the payload can be any of the three as
mentioned in the TRP specs.

	We still need to work out the integration.

cheers