Subject: Questions regarding RAs

From: "Aniruddha Shrotri" <[email-masked]>
Date: Tue, 16 Feb 1999 14:22:31 -0000

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 ?

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.

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.

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 ?

I have tried to look at the mailing list archives to see if these issues
were discussed before, but could not find any definitive references. It is
possible that I might have missed some threads and I apologize in advance if
that indeed has happened.

Thanks

Ani

----------------------------------------------
Aniruddha P. Shrotri (ani)
Director Engineering, E-Lock Technologies Inc.
----------------------------------------------

---

From: Al Arsenault <[email-masked]>
Date: Tue, 16 Feb 1999 08:11:31 -0500

Ani,

	In answer to some of your questions:

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

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

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

>case, how does the RA route the cert request it gets from an end entity

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.