Subject: RE: forward & reverse elements - population

From: "PACHL, Jan" <[email-masked]>
Date: Tue, 8 Sep 1998 12:37:04 -0700

in response to:
>From: 	David Boyce[SMTP:[email-masked]]
>"PACHL, Jan" writes:
>>If the forward and the reverse element are never both present in the
>>same pair (=either one is present or the other, but never both, in any
>>given pair), what is the point of having the attribute defined as
>>"pair"?
>>In that case it would make better sense to have two separate attributes
>>instead -- "forward certificate" and "reverse certificate".
>
>Well, we are trying to work with the defined X.509 attributes, so
>creating new ones which duplicate existing definitions will just muddy
>things further.  I agree, though, that things might have been 
>different.
>
Yes, I agree we should work with the defined attributes.
Presumably the crossCertificationPair attribute was defined as a pair
(and not as two separate attributes) for a good reason.

Jan Pachl
>SHL Systemhouse

---

From: Sharon Boeyen <[email-masked]>
Date: Tue, 8 Sep 1998 17:46:01 -0400

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 8, 1998 10:05 AM
> To: 	'Sharon Boeyen'; [email-masked]'
> Subject: 	RE: forward & reverse elements - population
> 
	--stuff deleted
> > 
> 	[]  I agree.  I do not have problem with the following language.
> " A certificate issued to a CA by another shall be stored either in the
> caCertificate or forward component of crossCertificatePair attribute of
> the subject CA.  Optionally, a subset of certificates issued by a CA can
> be stored in the reverse component of crossCertificatePair attribute of
> the issuing CA."
> 
> 	Please note that to me subset includes none, some, or all.  If
> folks want further clarification, it is ok by me.
> 
Santosh, the only issue I have with this text is that (at least with the
rationale behind option 2) any cert that appears in the cACertificate
attribute of a given CA
entry, should also appear in the crossCertificatePair attribute in the same
CA entry.
 What about deleting the reference to the cACertificate attribute from your
text and proposing this as new text just for the crossCertificatePair
attribute? 

Both Jan and David have indicated reasons to keep the "pair" together in the
mutual case, so we should also consider adding the last paragraph of the
text David proposed for that.  

Here's what the resulting text proposal would look like:

> " A certificate issued to a CA by another shall be stored in the
> forward component of crossCertificatePair attribute of
> the subject CA.  Optionally, a subset of certificates issued by a CA can
> be stored in the reverse component of crossCertificatePair attribute of
> the issuing CA. When both elements are present in the same value, the
> value shall represent a mutual cross-certification of the two CAs. "
> 
If we can come to consensus on that attribute, then let's see what we can do
with the cACertificate attribute text.

I agree with your view on what a subset is and I think that same definition
would apply to the contents of the cACertificate attribute as a subset of
the crossCertificatePair forward elements in option 2.

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 9 Sep 1998 11:01:32 -0400

I agree that the texts below are consistent with the original intent of the
2 options and I also agree that they are clearer than the original texts
except, possibly for coverage of self issued certificates. Shouldn't we also
state explicitly that self issued certs are stored only in the cACertificate
attribute for both options? 

> Sent: 	September 9, 1998 9:08 AM
> To: 	'Sharon Boeyen'; [email-masked]'; Santosh Chokhani
> Sharon:
> I can agree to the following text for the two option instead.  Please
> note that I have further clarified cross-certificate by tying the DN and
> public keys.
> 
> I think the following texts are consistent with and further
> clarifications of the two options.
> 
> I STILL AM STRONGLY IN FAVOR OF OPTION 1.
> 
And I option 2 :-)

> NEW PROPOSED TEXT FOR OPTION 1
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store certificates
> issued to this CA by CAs in other domains.  Optionally, the reverse
> element of the crossCertificatePair attribute, held in a particular CA's
> directory entry, may contain a subset of certificates issued by this CA
> to other CAs.  When both the forward and the reverse elements are
> present, issuer name in one certificate shall match the subject name in
> the other and vice versa, and the subject public key in one certificate
> shall be capable of verifying the digital signature on the other
> certificate and vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> NEW PROPOSED TEXT FOR OPTION 2
> 
> The cACertificate attribute, held in a particular CA's directory entry,
> shall be used to store certificates issued to this CA by CAs in the same
> domain as this CA.
> 
> The forward element of the crossCertificatePair attribute, held in a
> particular CA's directory entry, shall be used to store all certificates
> issued to this CA.  Optionally, the reverse element of the
> crossCertificatePair attribute, held in a particular CA's directory
> entry, may contain a subset of certificates issued by this CA to other
> CAs.  When both the forward and the reverse elements are present, issuer
> name in one certificate shall match the subject name in the other and
> vice versa, and the subject public key in one certificate shall be
> capable of verifying the digital signature on the other certificate and
> vice versa.
> 
> In the case of V3 certificates, none of the above CA certificates shall
> include a basicConstraints extension with the cA value set to FALSE.
> 
> The definition of domain is purely a matter of local policy.
> 
> 
> 
> > -----Original Message-----
> > From:	Sharon Boeyen [SMTP:[email-masked]]
> > Sent:	Tuesday, September 08, 1998 5:46 PM
> > To:	[email-masked]'; 'Santosh Chokhani'

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Sep 1998 11:26:42 -0400

Yes. I agree.  The following is the revised text.

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.  If there are any self-issued certificates and they
require publication, the caCertificate attribute shall be used to store
them.

The cACertificate attribute, held in a particular CA's directory entry,
shall be used to store certificates issued to this CA by CAs in the same
domain as this CA.  If there are any self-issued certificates and they
require publication, the caCertificate attribute shall be used to store
them.

> Sent:	Wednesday, September 09, 1998 11:02 AM
> > > > " A certificate issued to a CA by another shall be stored either
> in
> > > the
> > > > caCertificate or forward component of crossCertificatePair
> attribute
> > > of
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA."
> > > > 
> > > Santosh, the only issue I have with this text is that (at least
> with
> > > the
> > > entry, should also appear in the crossCertificatePair attribute in
> the
> > > same
> > > CA entry.
> > >  What about deleting the reference to the cACertificate attribute
> from
> > > your
> > > Both Jan and David have indicated reasons to keep the "pair"
> together
> > > in the
> > > mutual case, so we should also consider adding the last paragraph
> of
> > > the
> > > > the subject CA.  Optionally, a subset of certificates issued by
> a CA
> > > can
> > > > be stored in the reverse component of crossCertificatePair
> attribute
> > > of
> > > > the issuing CA. When both elements are present in the same
> value,
> > > the
> > > If we can come to consensus on that attribute, then let's see what
> we
> > > can do
> > > would apply to the contents of the cACertificate attribute as a
> subset
> > > of

---

From: "Kurn, David" <[email-masked]>
Date: Wed, 9 Sep 1998 09:15:34 -0700

Santosh

Sorry to ask what must be a very naive question.  If, as you suggest, the
"definition of a domain is purely a matter of local policy", then I think
that the term "domain" is undefined for the purposes of a standard.  If so,
then I find it difficult to define any algorhithm (not necessarily computer
based) or any process by which anyone could determine whether a CA is in the
same or a different domain.

Think, for example, of a general purpose application program (like a mail
client) trying to answer the question "is that CA inside or outside of my
domain".  

Back in my college days, my math professors made it painfully clear that if
you define a set, you must also provide a rule whereby you can determine
whether a given element is inside or outside of that set.  Without such a
rule, the set is undefined.

It may be that the definition of "domain" is elsewhere in the document, but
I cannot find it.

David Kurn
Compaq Computer Corp
Electronic Commerce Stuff

> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 8:27 AM

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Sep 1998 12:53:12 -0400

David:

In both options 1 and 2, a relying party can determine which issuing CAs
are considered in the domain of the subject CA by looking at
caCertificate attribute and the forward element of the
crossCertificatePair attribute.

In option 1, it is straightforward.

In option 2, you have to subtract the caCertificate from the
crossCertificatePair to get the two sets.

These two domains are from the subject CA's perspective.  It may or may
not be in the domain of the relying party.

> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 12:16 PM
> To:	'Santosh Chokhani'; 'Sharon Boeyen'; [email-masked]'
> > > I agree that the texts below are consistent with the original
> intent
> > > of the
> > > except, possibly for coverage of self issued certificates.
> Shouldn't
> > > we also
> > > > note that I have further clarified cross-certificate by tying
> the DN
> > > and
> > > > public keys.
> > > > 
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.
> > > > 
> > > > element of the crossCertificatePair attribute, held in a
> particular
> > > CA's
> > > > directory entry, may contain a subset of certificates issued by
> this
> > > CA
> > > > present, issuer name in one certificate shall match the subject
> name
> > > in
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > shall be used to store certificates issued to this CA by CAs in
> the
> > > same
> > > > domain as this CA.
> > > > 
> > > > CAs.  When both the forward and the reverse elements are
> present,
> > > issuer
> > > > name in one certificate shall match the subject name in the
> other
> > > and
> > > > capable of verifying the digital signature on the other
> certificate
> > > and
> > > > vice versa.
> > > > 
> > > > In the case of V3 certificates, none of the above CA
> certificates
> > > shall
> > > > > > value shall represent a mutual cross-certification of the
> two
> > > CAs. "
> > > > > > 
> > > > > I agree with your view on what a subset is and I think that
> same
> > > > > definition

---

From: "Kurn, David" <[email-masked]>
Date: Wed, 9 Sep 1998 10:50:42 -0700

Santosh

Hmm.... I think I see.  Perhaps the problem arises because of your use of
the word domain.  Consider your 2nd and 3rd paragraph rewritten to omit the
word "domain", such as:

	The relying party will start with the assumption that the
	subscriber with whom it is trying to form a key management
certificate
	path or digital signature certificate verification path is reachable
by starting with the entries in the caCertificate Attribute.

	If the above search fails, the
	relying party will continue with the assumption that the subscriber
with
	whom it is trying to form a key management certificate path or
digital
	signature certificate verification path is reachable by using the
forward element of the crossCertificatePair attribute under
	option 1 and forward element of the (crossCertificatePair -
	caCertificate) under option 2 first.

Does this capture your intent and avoid the word "domain"?

Of course, I don't like my algorithm,  because it appears to imply a search
to the end before trying the other branch.

David Kurn

> Sent:	Wednesday, September 09, 1998 10:32 AM
> To:	Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; [email-masked]'
> Let us say an application requires more communication within a domain.
> 
> Then the relying party will start with the assumption that the
> subscriber with whom it is trying to form a key management certificate
> path or digital signature certificate verification path is also in the
> same domain and hence will follow the caCertificate attribute link
> first.
> 
> If the application requires more communication across the domain, the
> relying party will start with the assumption that the subscriber with
> whom it is trying to form a key management certificate path or digital
> signature certificate verification path is in another domain and hence
> will use forward element of the crossCertificatePair attribute under
> option 1 and forward element of the (crossCertificatePair -
> caCertificate) under option 2 first.
> 
> If there is no bias in communication intra or inter domain, the relying
> party has lost nothing and will always find a trust path, if there is
> one.
> 
	<SNIP>

---

From: "Kurn, David" <[email-masked]>
Date: Wed, 9 Sep 1998 10:12:22 -0700

Santosh

I seem to sense a circularity of definition.   If I interpret your comment
correctly, you place a cert in the caCertificate attribute if it belongs to
the same domain, and you can determine that it's in the same domain by
seeing if it's in the caCertificate attribute.  Exactly how I would use this
in a computer program is unclear.   Perhaps you could sketch out some
program logic one would use.

David

> Sent:	Wednesday, September 09, 1998 9:53 AM

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Sep 1998 13:32:28 -0400

> Sent:	Wednesday, September 09, 1998 1:12 PM
> > > Sorry to ask what must be a very naive question.  If, as you
> suggest,
> > > the
> > > "definition of a domain is purely a matter of local policy", then
> I
> > > think
> > > that the term "domain" is undefined for the purposes of a
> standard.
> > > If so,
> > > based) or any process by which anyone could determine whether a CA
> is
> > > in the
> > > Think, for example, of a general purpose application program (like
> a
> > > mail
> > > client) trying to answer the question "is that CA inside or
> outside of
> > > my
> > > domain".  
> > > 
> > > Back in my college days, my math professors made it painfully
> clear
> > > that if
> > > > domain as this CA.  If there are any self-issued certificates
> and
> > > they
> > > > require publication, the caCertificate attribute shall be used
> to
> > > store
> > > > them.
> > > > 
> > > > domain as this CA.  If there are any self-issued certificates
> and
> > > they
> > > > require publication, the caCertificate attribute shall be used
> to
> > > store
> > > > them.
> > > > 
> > > > > 2 options and I also agree that they are clearer than the
> original
> > > > > texts
> > > > > > I can agree to the following text for the two option
> instead.
> > > > > Please
> > > > > > The cACertificate attribute, held in a particular CA's
> directory
> > > > > entry,
> > > > > > The forward element of the crossCertificatePair attribute,
> held
> > > in a
> > > > > > to other CAs.  When both the forward and the reverse
> elements
> > > are
> > > > > > include a basicConstraints extension with the cA value set
> to
> > > FALSE.
> > > > > > 
> > > > > > The cACertificate attribute, held in a particular CA's
> directory
> > > > > entry,
> > > > > > The forward element of the crossCertificatePair attribute,
> held
> > > in a
> > > > > > entry, may contain a subset of certificates issued by this
> CA to
> > > > > other
> > > > > > vice versa, and the subject public key in one certificate
> shall
> > > be
> > > > > > include a basicConstraints extension with the cA value set
> to
> > > FALSE.
> > > > > > 
> > > > > > > > 	[]  I agree.  I do not have problem with the
> following
> > > > > language.
> > > > > > > > " A certificate issued to a CA by another shall be
> stored
> > > either
> > > > > in
> > > > > > > the
> > > > > > > > the subject CA.  Optionally, a subset of certificates
> issued
> > > by
> > > > > a CA
> > > > > > > can
> > > > > > > > 	Please note that to me subset includes none,
> some, or
> > > > > all.  If
> > > > > > > > " A certificate issued to a CA by another shall be
> stored in
> > > the
> > > > > > > > the subject CA.  Optionally, a subset of certificates
> issued
> > > by
> > > > > a CA
> > > > > > > can
> > > > > > > If we can come to consensus on that attribute, then let's
> see
> > > what
> > > > > we
> > > > > > > can do
> > > > > > > would apply to the contents of the cACertificate attribute
> as
> > > a
> > > > > subset
> > > > > > > of

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Sep 1998 14:04:50 -0400

You seem to have captured the essence.

Please note that the preference could be reversed depending on the
application need and/or the environment.

You have to try a search to the end.  I do not think in graphs like this
there is an a priory way of encoding which links will lead to which
paths.  Depth first (or up to some depth) search is likely to be the PKI
path development strategy in combination with judicious use of AKID,
SKID, key usage, pathToName, and certificate policy matching rules.

> Sent:	Wednesday, September 09, 1998 1:51 PM