Re: Trust Anchor/Registry Security

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Following posted on behalf of Steve Hanna. Steve is a security expert
and has helped Krishna and I with the Registry Security proposal.

--
Regards,
Farrukh

---

• From: Steve Hanna <steve.hanna@sun.com>
• To: Farrukh Najmi <Farrukh.Najmi@east.sun.com>,Rich Salz <rsalz@caveosystems.com>
• Date: Tue, 16 Jan 2001 15:33:35 -0500

I tried to send the attached message to ebxml-regrep and got this bounce
message. Could you resend my message if it didn't get through?

Thanks,

Steve

-------- Original Message --------
Subject: Not authorized to submit to elist: ebxml-regrep
Date: Tue, 16 Jan 2001 15:25:03 -0500 (EST)
From: ebxml-regrep-help@lists.ebxml.org
To: steve.hanna@Sun.COM

Your message to the elist is being returned to you because you are not
authorized to submit messages to the elist.  There are only two possible
reasons for this.

1. The elist is restricted and very few people are permitted to submit
   messages.  If you think you are one of those very few people replying
   to this message will put you in touch with a person with whom you may
   discuss the issue.

2. The elist only permits subscribers to submit messages to it.  The
   test of whether or not you are a subscriber is a comparison of your
   envelope from header with the email addresses of the list of
   subscribers.  The envelope from header is the value specified by your
   email system as the origin of the message.  This is different than
   the message from header which is specified by your email client and
   what you see whenever you display an email message.

   If you believe you are subscribed to this elist and should be able to
   submit messages to it, replying to this message will put you in touch
   with a person with whom you may discuss the issue.

---

• From: Steve Hanna <steve.hanna@sun.com>
• To: Krishna Sankar <ksankar@cisco.com>
• Date: Tue, 16 Jan 2001 15:18:07 -0500

Overall, this looks fine. A few minor comments:

Krishna Sankar wrote:
>         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.

The registry could also contact an OCSP responder to determine the
revocation status of a certificate.

Remember also that validating a certificate involves more than just
checking its revocation status. It is necessary to build a path of
certificates from one of the registry's trust anchors to the certificate
in question and validate this path. For the X.509 or PKIX validation
algorithms, this involves checking name constraints, basic constraints,
policy constraints, etc. Also, the key usage and extended key usage in
each certificate must be checked to determine whether the certificate is
being used in a manner consistent with the purposes described there.
Most registry implementations will probably use a certification path
validation library to perform this validation (such as the Getronics
Certificate Management Library or the Java Certification Path API).

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

The registry's trust anchors would vary, depending on whom the registry
trusts. Many registries might use the same set of trust anchors as most
web browsers, for simplicity. But some would probably prefer a smaller
set of more trusted parties, for greater security.

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

Yes, it is probably best to avoid requiring a specific validation
technique. But you might want to refer to IETF RFC 2459. This RFC
describes PKIX validation and it's a solid choice.

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

Right.

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

Right. Registry implementations should have configuration parameters
that allow the administrator to configure these policies when setting up
the registry. Reasonable defaults should be provided.

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

Right. The registry client's set of trust anchors may not match the set
used by the registry. To improve the likelihood that clients will be
able to verify the signature on the content, the signer may want to
include several certificates signed by different CAs. Verifying the
revocation status of a certificate can be difficult, but the
CRLDistributionPoints and AuthorityInformationAccess extensions should
make this easier. For some lower security applications, the client may
be willing to forgo revocation checking altogether.

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

That's a good idea. Thanks for sharing your thoughts.

-Steve

---

---

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard