Re: Questions regarding RAs

[Al Arsenault <aarsenault@xxxxxxxxxx>]

Ani,

	In answer to some of your questions:



At 02:22 PM 2/16/99 +0000, Aniruddha Shrotri wrote:
>Hi all,
>
>I have some questions related to Registration Authorities (RAs), variously
>referred to as LRAs, ORAs, registration agents in various parts of the PKIX
>suite of drafts and falls under the PKI Management entities category:
>
>
>1. In the model where a CA is serving several RAs which in turn are serving
>several EEs each, are there any formal ways for the CA to divide the
>name-space between the RAs ? In case of CA hierarchies, the old PEM model
>used a strictly hierarchical structure even for name-spaces, i.e., the DN of
>a subordinate CA had to be strictly in the subtree with the parent CA as the
>root of that subtree, and similarly, the EEs' DN had to be in the subtree
>under the penultimate CA. Later, in the current standards, this was amended
>to use Name Space constraints. The parent CA can use Name Space constraint
>extension to limit the scope of a subordinate CA. However, this extension is
>currently defined only for a CA certificate. Would it make sense to use this
>extension for an RA certificate ? Or is the division of name-space between
>RAs a local implementation matter ?
>
>
AWA:  It's a local implementation matter.  Essentially, an RA is only
sending a request to a CA:  "Will you please sign & issue this cert, for
this user, whom I (may) have determined is the right owner, possesses the
private key, and is entitled to these properties?"  It's up to the CA to
make the decision and enforce whatever rules apply.

A CA's local policy could certainly be set up to enforce "RA's can only
request certificates in certain name subtrees, and any request for a name
not in that subtree will be rejected", but that shouldn't be mandated as
any part of a standard.


>
>2. Continuing on name-space issue, Section 5.1.2 of PKIX RoadMap says:
>
>"Suppose for example that a rootCA is established with DN "O=IETF,
>OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for names
>subordinate to it."
>
>Is this strictly true ? Is the CA required to issue certificates *only* for
>names subordinate to it ? This will be true only if the Name constraints in
>the CA's cert mention this DN in the included subtrees. In general, there
>need not be any relation between the CAs DN and the DN of the EEs that it
>is certifying. If it is there, it will only be a local policy /
>implementation issue and not an issue which standards should enforce.
>

AWA:  Oops, darned unfortunate wording there.  That section is referring to
the fact that names in PKIX don't have to be "globally unique", just unique
within a domain of interest.  Name constraints and "name subordination"
aren't even relevant.  We'll figure out some alternative wording that gets
the same point across, without dragging in name constraints.

>
>3. How does one figure out from an EE's cert which RA it belongs to ? Is
>this even a requirement ? What bearing does the current thread of discussion
>"Finding PKIX Servers" have on this question, considering that the EEs will
>typically consider the RAs as their PKIX Server.
>

AWA:  This is a "local matter", you can't in general expect to find out
which RA to contact from looking at an EE's cert.  If you really wanted to
do it in your specific case, there are several ways it could be
accomplished, but it's not mandatory and not everybody wants to do it.

>
>
>
>4. What purpose does a "hierarchy" of RAs serve ? Particularly, considering
>that the "hierarchy" of RAs would have no relation to the trust hierarchy.
>That is, is it reasonable to have an architecture where an RA registers
>not only end entities (EEs) but other RAs ? CMC allows for such a thing and
>other parts of PKIX drafts do not preclude it. It does have some utility for
>distributing the proofing and registration responsibilities. But couldn't
>same purpose be served by having additional RAs at the same level ?
>
>
>
>5. Does it make sense for a top level RA to be under multiple CAs ? This
>certainly is indicated as a possibility in section 1.2.3 of CMP. In this
>case, how does the RA route the cert request it gets from an end entity
>to the appropriate CA ?
>

AWA:  Yes, I've built PKIs in which RAs are subordinate to mulitple
different CAs.  Basically, the RA has to have a database/rule engine/some
other algorithm by which it looks at an EE request and says "this goes to
CA1" or "this goes to CA2".  For example, the RA could make its decision
based on the EE's name; or on the source of the request (e.g, the subnet or
domain); or on some other attribute in the requested certificate.


					Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.