Trust Anchor/Registry Security

[Krishna Sankar <ksankar@cisco.com>]

Hi all,

	During today's con call, Chris raised a good point about the CRLs and
certificate validation for the Registry. Here are my thoughts on the issue.
Would appreciate comments and ideas.

	1.	From the registry's point of view, the security scenario is as follows.

		a)	For query, no certificate/signed message is required (Guest role)
		b)	For submitting content, header should be signed (using XMLDSig) and the
DN from the certificate would be used as the identity. As anybody can
submit, this DN would be added as the principal. (SO Role)

			The content should be signed as well.

		c)	For update/delete content, header should be signed and the DN from the
cert will be used for identification. If the DN is the same as b) above the
update/delete operation would be allowed (SO Role)

		d)	When a registry is created, it should have the DN of the admin (Admin
Role). In case of admin actions, the header should be signed and if the DN
is the same as the DN of the admin (stored in the registry) then that action
will be allowed.

	2.	No self signed certificate is allowed. That means the certificate should
be from a reputed CA - which might be the security anchor

	3.	Then the question is how do we validate a certificate ? Most probably,
the registry would get the CRLs from the CA and make sure that the
certificate is not revoked.

		And of course, the registry would have the root certificate of all the
popular CAs (like the web browser does) to validate the authenticity of the
certificate.

		This process is specific to a registry implementation, and so we should
not mandate any specific implementation. We can say, the certificate
authenticity should be validated.

		For some registries, they themselves might act as CAs and issue
certificate out of band. For example for an internal IBM registry, IBM might
be the CA. and IBM might be the CA for it's trading partners as well.

		Now going back to 2) the CA and PKI policy would be set by the registry
operator to suit it's purpose.

	4.	When a party receives retrieves content from the registry, the content
would be signed. The party would use the normal mechanisms to validate the
signature, certificate etc. If one gets a certificate for which one has no
root certificate or one has nowhere to go for a trusted CRL, then that
content cannot be trusted for mission critical applications.

	5.	BTW, as a general principle, as Chris and others suggested, the content
can be signed using PGP or XMLDsig or any other mechanism. This process is
outside the TRP and even the registry. But as Farrukh pointed out, we will
recommend XMLDSig and will use the XMLDSig for the POC, demos et al.

	Sorry for the long e-mail. But I wanted to amplify my position re
certificates during the con call. Please feel free to flamme ;-) I think we
should have a few paragraphs on this issue somewhere in the registry
specification.

	cheers