RE: comments on the Registry Proposal -002.doc

[Krishna Sankar <ksankar@cisco.com>]

MH,

	Thanks for your comments. I am incorporating your suggestions and ideas. My
replies are embedded.

cheers

ALL,

	I would appreciate if you could send comments as well. May be you will get
a little time between those Santa visits to think about ebXML Security ;-)

	We need to get a simple yet effective security mechanisms *across* all
layers of ebXML soon.

cheers

> -----Original Message-----
> From: Maryann Hondo [mailto:mhondo@us.ibm.com]
> Sent: Thursday, December 21, 2000 5:49 AM
> To: Farrukh.Najmi@east.sun.com; Krishna Sankar
> Cc: ebxml-ta-security@lists.ebxml.org
> Subject: comments on the Registry Proposal -002.doc
>
>
> HI,
>
> I'm sorry it took me so long to review this.
> I was going to participate in the R&R call, but it looks like the security
> discussion
> has been postponed.  Please let me know if this heats up again.
<KS>
It has just started. It is going to get much hotter soon ;-)
</KS>
>
> So, here's my comments.
>
> First, THANK YOU.
>
> General comments
>
> I think you need to explain a little about what objects are persistent and
> which are transient.
> Maybe its just that I haven't read the R&R specs in a while, and
> if this is
> folded in with that document
> then it may not be an issue, but its hard to grasp when the security
> objects, like permissions or principals
> are created and when they go away (which can be a security issue in
> itself).
<KS>
Yep. Good idea. Will incorporate
</KS>
>
> I also think we need to try to develop a CPP for this. Isn't this just a
> case of a "business process"?
> If we could do that it might help people see how these specs fit together.
> The CPP could define the different
> roles and also demonstrate the security needed at each
> level....for example
> the "reader" role would not need
> any security on its request message, as opposed to the "document owner"
> role needing authentication.
>
<KS>
Good. Then we will abstract the security interactions to different roles and
provide a CPP for it. This looks like a Phase 2 feature. By that time, we
also would have added more capabilities (like ability to add roles etc) to
the Registry and the CPPs would be mature (past Version 1.0 specs)
</KS>
> Also, there seems to be both "DN" and "CN" used throughout the document.
> Do you mean both
> Distinguished Name and Common Name?  Also we may need a slight intro or
> background from maybe
> an IETF doc to explain what these are (I'll look and see if I can find
> something)
<KS>
I think DN is the way to go. Please let me know the reference. My plan is to
avoid definitions as far as possible and refer to external documents which
are kind of experts in the field and/or general standards.
You are right - there are equal numbers of DNs and CNs ;-0 I have changed
all CNs to DNs.
</KS>
>
> I wonder if we shouldn't define both Identification and Authentication.
> Identification being the collection of
> names and authentication being the actual step that proves the identity.
>
<KS>
Good. I will add these along with the transient/persistent discussion
</KS>
> Under section 1.4,
> line 87, how about  "An issue related to confidentiality and integrity is
> the appropriate access to
> the data, or authorization."   My point being it's not just
> confidentiality.
>
<KS> Sounds better. Thanks and I have incorporated your change</KS>
> Don't you think we need to make some statement about audit for
> R&R? I think
> it's essential due to the name control
> being assigned to the data.
<KS>
I agree. If you can suggest some words, I will add them
</KS>
>
> Under Requirements,
>
> line 99, Do we really need #1 or can it be combined with #5?
<KS>
Yes, #5 implies #1. But I wanted to mention the user level and document
level security specifically so that there is no ambiguity.
</KS>
>
> line 118, The term "authenticator" is used without being defined, I
> believe. Otherwise I missed it !
<KS>
Yep, the authenticator is catching a lot of flack ! I have changed it to
"registry authentication service". Are you OK with that ?
</KS>
>
> How about "Document Reader" instead of "DocumentUser"?
<KS>
As per Scott Newman's suggestion, I plan to refer to roles in ISO-1719 and
have a map to the registry related internal roles. Most probably they would
be the same. Please review the next document (version 003-to be released
soon at an e-mail alias near you ;-) and pl comment on them as well.
</KS>
>
> line 127 , How about...." The authorization scheme should be flexible
> enough to allow public and private areas within the registry"  ?
<KS>
For you anything ;-) I have made the change. Sounds better
</KS>
>
> line 135 Can we define spoofing?  Do you mean an entity posing as a
> registry when its not a registry?
<KS>
Yep. I want to modify the sentence as "an entity posing as the intended
registry when its not the intended registry". Does it make sense ? Also, we
should add some security reference on spoofing.
</KS>
>
> Under section 3
>
> Can we differentiate between ContentOwner having * privileges on ONE
> element vs  RegistryAdministrator who has * privileges on ALL elements.
<KS>
Yep. Thanks.
</KS>
>
> line 165, "For phase 1 read clients need not use certificates...."?
>
> line 180 "Phase 1 will rely on TRP for message level authentication,
> confidentiality and integrity"  Are we asserting that message headers as
> well as payload needs to be signed? or is payload signing/encryption
> sufficient? If the content is encrypted, the R&R MUST be able to get the
> key to decrypt.....we need to make sure this is part of the TR&P profile.
<KS>
Now we are getting into murky waters !
Here is what the Registry needs from TRP. (I am also sending this as a
separate e-mail)
1.	Authentication - for now means signed headers. The TRP spec should have
the semantics and syntax how to do this. Then the registry can say
HeaderSignatureRequired in the CPA and use the signature to validate the
identity of the user.

2.	Submitting organizations should sign the content.

	a)	Remember this could be different from the authentication
certificates/credentials above.
	b)	This signature ensures integrity.
	c)	This is required not only for the registry but also for the clients who
refer to the content for biz critical apps
	d)	So the content and the signature will be stored.
	e)	When a client receives a content(which has the signature as well), it
should check the integrity
	f)	I saw that even the CPP would require a signature for integrity.
	g)	In this context, the TRP would RECOMMEND the semantics and syntax for
signing and encryption. One caution here is that the MSH should give the
content to the Registry with the signature.
</KS>
>
> line 207-210, I'm not sure how this will be done.
<KS>
We are still working on the Information Model. I will try to clarify this as
an Appendix. Also I plan to think thru and implement it - which might
clarify more.
</KS>
>
> line 229 is where I first noted the switch from DN to CN mentioned above.
<KS>
Thanks. I have changed all CNs to DNs.
</KS>
>
> line 239,243.....do we want this "any" match to be the only rule?  I think
> we need to allow for this to change over time and so we might
> want to leave
> authorization policy to the registry to define.
>
<KS>
Good point. Actually Farrukh and Ron of Sun have added a policy object to
handle this and other related scenarios. Please keep the thought and tell us
if the next info model solved this issue.
</KS>
>
> line 249, isn't this "processing done by the DocumentOwner"?  or at least
> "Registry Client acting as Document Owner", right?
>
<KS>
Line 249 says that we need an identity object (with the DN of the admin's
certificate) for the RegistryAdmin so that we have a pseudo super user in
place. Can you explain your thoughts ? Or are you referring to some other
line ?
</KS>
> line 262, I'm assuming "SO" is "submitting organization" but we should
> probably spell this out the first time.
>
<KS> yep. Done </KS>

<KS>
MH, I thank you for your insightful comments. Cheers and have a happy
holidays
</KS>