Re: Root DSA

Andrew Waugh <> Fri, 04 November 1994 03:19 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa12920; 3 Nov 94 22:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12916; 3 Nov 94 22:19 EST
Received: from by CNRI.Reston.VA.US id aa23464; 3 Nov 94 22:19 EST
Received: from by with local SMTP id <>; Fri, 4 Nov 1994 02:52:31 +0000
Received: from shark.mel.dit.CSIRO.AU by with Internet SMTP id <>; Fri, 4 Nov 1994 02:52:15 +0000
Received: from conger.mel.dit.CSIRO.AU by with SMTP id AA16058 (5.65c/IDA-1.4.4/DIT-1.3 for; Fri, 4 Nov 1994 13:51:40 +1100
Message-Id: <>
Subject: Re: Root DSA
In-Reply-To: Your message of "28 Oct 1994 22:57:00." <"">
Date: Fri, 04 Nov 1994 13:51:39 +1100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Waugh <>


A couple of comments on "Phasing Out The Root DSA"

1) You might like to give some thought as to terminology (or include some
diagrams). It is sometimes hard to visualise exactly what is data is being
passed around.

My suggestion is to define the term 'psuedo-context' (or something equivalent).
This is a context consisting of the Root entry and *one* subordinate reference.
For example the Australian First Level DSA would hold a psuedo-context
containing the root and the subordinate reference for the context <c=AU>. (It
would also, of course, normally hold the context <c=AU> as well.)

The process described in your note is then simply that of collecting together
these psuedo-contexts to form a proper context and redistributing this context
to the First Level DSAs.

Your long term solution can then be described as using a HOB to copy the
subordinate references from the psuedo-contexts to the Psuedo Root DSA which
builds the root context. It then uses a SOB to distribute this context back
to the First Level DSAs.

2) The implementation issues then become:
   a) Can a Psuedo Root DSA amalgamate the data it is receiving from the
      HOBs into a full context?
   b) How will the First Level DSAs handle receiving the root context from the
      Psuedo Root DSA which includes their own psuedo-contexts?
It may be that special code needs to be added to the First Level DSAs to
handle these cases.


> 11. The European coordinating point can operate a (pseudo) root DSA that
> enters into two bilateral agreements with every master First Level DSA. One
> of these agreements will be a shadowing agreement, the other a hierarchical
> agreement. 
> 12. Every master First Level DSA will shadow the root context from the root
> DSA. This will provide the complete set of subordinate references. This is
> the shadowing agreement, and should be completely standard (otherwise
> shadow First Level DSAs could not be supported by the implementation). 
> [...]
> 13. The root DSA will enter into a hierarchical agreement with every master
> First Level DSA, in order to obtain a subordinate reference for each first
> level entry. Whilst hierarchical agreements are standardised, this
> particular novel use of a HOB is not specifically recognised in the
> standard so it may cause hiccups with some implementations, although the
> ASN.1 will support it. 
> [...]

I would suggest reversing points 12 and 13. First describe how the (pseudo)
root DSA receives updates from the First Level DSA (the true masters of each
first level context), and then how this (pseudo) root DSA distributes the
co-ordinated set of first level contexts to the First Level DSAs.

The reason for this change is that, on first reading, it appears that you are
suggesting keeping the concept of a root DSA (i.e. having a single master First
Level DSA) with all other First Level DSAs being shadows. Reversing the order
of the points highlights that the true source of the first level contexts is
actually the set of First Level DSAs.


> 11. The European coordinating point can operate a (pseudo) root DSA that
				      ^^^ will


> 15. An alternative solution, which is much less manageable, but that does
> without a pseudo root DSA, is for each master First Level DSA to enter into
> bilateral agreements with every other master First Level DSA, in order to
> shadow the first level entries and access point operational attributes.
> However, this solution is not seriously proposed, as the management
> overheads are too great.

While it is less managable, it has the advantage that there is no single point
of failure. This is an issue with the Psuedo Root DSA approach (though not a
large one) and should be pointed out.

andrew waugh