Subject: [pkix] Trust Constraints - Possible request for yet another certificate extension

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 May 2011 12:14:38 +0200

All,

I have come across a need that I don't know how to solve with the existing
certificate extensions.
I would like to discuss what the best solution is, which may include
defining a new extension.

I'm running a cross certifying PKI which extracts a fairly large number of
intermediary CAs and certifies them under a single root.
I create a number of root authorities, each representing a different policy
for approving CAs to be certified under this root.

Example: 
Root 1 only certifies CA:s that issues qualified certificates

I would like to include some optional information in the root certificate
that the relying party MAY use to understand policy used to certify CAs
under that root.
A relying party using this root MAY use this information to apply extra
controls, such as verifying that the end entity certificate being verified
under that root is a qualified certificate by examining the QcStatements
extension from RFC 3739.

So the options I have considered and dismissed are:

- certificate policy extension, and
- EKU

Both are bad. The policy extension is designed to list certificate policies
that can be included in the EE cert (that is what the path validation
algorithm does). The EKU is only meant to be included in EE certs and its
inclusion in other certs is subject to non-standardized handling that makes
such solution highly unpredictable.

The cleanest way that I can think of is to include such information in a new
extension along this structure:

TrustConstraints :== SEQUENCE OF TrustConstraint
TrustConstraint :== SEQUENCE {
  constraint     OBJECT IDENTIFIER,
  constraintInfo  OCTET STRING  OPTIONAL }

The constraintInfo content is defined by the constraint OID. The reason why
I put it in an OCTET STRING is because it is way easier to code than having
an "any defined by" structure. This way I can always parse this extension
with a simple fixed ASN.1 structure and pass the byte[] array to higher
logic for processing if I recognize the OID, or else trash it. The
constraints data could for example carry XML data or a JSON object according
to the definition of the constraint OID. This way we would not have to
bother with I18N stuff in the extension definition. Clean and simple.

This extension is only meant to be placed in CA certificates, possibly only
in self signed root certificates.

Thoughts?

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 23 May 2011 13:46:20 +0200

Stefan,
You said: "This extension is only meant to be placed in CA certificates, possibly only in self signed root certificates".
I do not believe, it is a good idea.
A CA may certify many other CAs for different purposes. It is the end-user or the application that will decide 
which intermediate or end-entity certificates may be trusted.
The right placement of constraints is in a signature policy or in a validation policy.
For signature policy formats, refer to ETSI TR 102 038 V1.1.1 (2002-04) or ETSI TR 102 272 V1.1.1 (2003-12).

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : [email-masked] 
Date : 2011-05-23, 12:14:38
Sujet : [pkix] Trust Constraints - Possible request for yet another certificateextension

All,

I have come across a need that I don't know how to solve with the existing certificate extensions.
I would like to discuss what the best solution is, which may include defining a new extension.

I'm running a cross certifying PKI which extracts a fairly large number of intermediary CAs and certifies them under a single root.
I create a number of root authorities, each representing a different policy for approving CAs to be certified under this root.

Example: 

I would like to include some optional information in the root certificate that the relying party MAY use to understand policy used to certify CAs under that root.
A relying party using this root MAY use this information to apply extra controls, such as verifying that the end entity certificate being verified under that root is a qualified certificate by examining the QcStatements extension from RFC 3739.

Both are bad. The policy extension is designed to list certificate policies that can be included in the EE cert (that is what the path validation algorithm does). The EKU is only meant to be included in EE certs and its inclusion in other certs is subject to non-standardized handling that makes such solution highly unpredictable.

The cleanest way that I can think of is to include such information in a new extension along this structure:

The constraintInfo content is defined by the constraint OID. The reason why I put it in an OCTET STRING is because it is way easier to code than having an "any defined by" structure. This way I can always parse this extension with a simple fixed ASN.1 structure and pass the byte[] array to higher logic for processing if I recognize the OID, or else trash it. The constraints data could for example carry XML data or a JSON object according to the definition of the constraint OID. This way we would not have to bother with I18N stuff in the extension definition. Clean and simple.

This extension is only meant to be placed in CA certificates, possibly only in self signed root certificates.

Thoughts?

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 May 2011 15:10:46 -0400

Stefan,

>From your description it is not clear if you mean this as a capability or constraint?

Specifically, is the Root 1 only good for qualified certificates and nothing else?  Another example is what does the absence of this constraint means?

I am guessing that you mean this as a capability and not a constraint.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Monday, May 23, 2011 6:15 AM
To: [email-masked]
Subject: [pkix] Trust Constraints - Possible request for yet another certificate extension

All,

Example:

Thoughts?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 May 2011 21:39:20 +0200

I intend to use this in my validation software to constrain what certificate
that are accepted as valid.

In my use case this maps to the information about trust services that is
provided in EU Trust service lists.
I may include information in the root declaring that only qualified EE
certificates are supposed to be validated under this root.

I may however include CA certificates that are only used to validate
timestamps and OCSP responses to support signature validation of signatures
based on qualified certificates. I could then include information in the CA
certificates to OCSP responders and CAs certifying TSAs that they are to be
used only to validate time stamp tokens and OCSP responses. That way I will
avoid using them by mistake to validate a qualified certificate.

As I said, I can't put this in certificate policies, because I control the
issuance of end entity certs and what policies they use.

So one constraintsInfo I would like to be able to include is the
TrustServiceType declaration carried for that CA in an EU Trust Service
List. That tells me if that CA is used to support time stamping, OCSP,
qualified certificates, regular EE certificates etc. This information about
the service is lost when I cross certify these CAs and I'm looking for a way
to store such information in the issued CA certificate so my validation
software can make use of it.

I care less if this is called capability or constraints, and more about the
capacity to store such information.
If not standardized here, I think I will just create a private extension for
this purpose, since I need it.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Mon, 23 May 2011 15:10:46 -0400
To:  Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  RE: [pkix] Trust Constraints - Possible request for yet another
certificate extension

> Specifically, is the Root 1 only good for qualified certificates and nothing
> else?  Another example is what does the absence of this constraint means?
>  
> I would like to include some optional information in the root certificate that
> the relying party MAY use to understand policy used to certify CAs under that
> root.
> 
> The constraintInfo content is defined by the constraint OID. The reason why I
> put it in an OCTET STRING is because it is way easier to code than having an
> "any defined by" structure. This way I can always parse this extension with a
> simple fixed ASN.1 structure and pass the byte[] array to higher logic for
> processing if I recognize the OID, or else trash it. The constraints data
> could for example carry XML data or a JSON object according to the definition
> of the constraint OID. This way we would not have to bother with I18N stuff in
> the extension definition. Clean and simple.
> 
>  
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 May 2011 21:42:34 +0200

Denis,

A signature policy is carried in the signature. That is kind of useless for
me.
That tells me nothing about the purpose of a CA that I find in my trust
store.

/Stefan

From:  Denis Pinkas <[email-masked]>
Reply-To:  <[email-masked]>
Date:  Mon, 23 May 2011 13:46:20 +0200
To:  pkix <[email-masked]>
Subject:  Re: [pkix] Trust Constraints - Possible request for yet another
certificate extension

> Stefan,
> 
> You said: "This extension is only meant to be placed in CA certificates,
> possibly only in self signed root certificates".
> 
>> De  : pkix-bounces <mailto :[email-masked]>
>>  
>> À  : [email-masked] <mailto :[email-masked]>
>>  
>> that the relying party MAY use to understand policy used to certify CAs under
>> that root.
>>  
>> to the definition of the constraint OID. This way we would not have to bother
>> with I18N stuff in the extension definition. Clean and simple.
>>  
>> 
>>  
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 May 2011 15:53:44 -0400

Stefan,

You miss the point.

The capability and constraint is not simply a terminology issue.

What you are saying is that if the constraint is present, then the CA can only be used for the listed purposes.  Right?

You are also saying that the constraint's absence means that the CA can be used for any purpose.  Right?

Here are some suggestions:

1.     This need not be in a root certificate.  It can be in root issued CA certificates unless you envision root to be direct issuer of end entity certificates

2.     I suggest you define both the permitted and excluded capabilities

3.     I suggest that the path validation logic honor the presence of this extension in downstream CAs a la name constraints

4.     I suggest you think about what the relying party should do if it does not understand semantics of one of the OIDs present in the extension, especially in the excluded field.
From: Stefan Santesson [mailto:[email-masked]]
Sent: Monday, May 23, 2011 3:39 PM
To: Santosh Chokhani; [email-masked]
Subject: Re: [pkix] Trust Constraints - Possible request for yet another certificate extension

I intend to use this in my validation software to constrain what certificate that are accepted as valid.

In my use case this maps to the information about trust services that is provided in EU Trust service lists.
I may include information in the root declaring that only qualified EE certificates are supposed to be validated under this root.

I may however include CA certificates that are only used to validate timestamps and OCSP responses to support signature validation of signatures based on qualified certificates. I could then include information in the CA certificates to OCSP responders and CAs certifying TSAs that they are to be used only to validate time stamp tokens and OCSP responses. That way I will avoid using them by mistake to validate a qualified certificate.

As I said, I can't put this in certificate policies, because I control the issuance of end entity certs and what policies they use.

So one constraintsInfo I would like to be able to include is the TrustServiceType declaration carried for that CA in an EU Trust Service List. That tells me if that CA is used to support time stamping, OCSP, qualified certificates, regular EE certificates etc. This information about the service is lost when I cross certify these CAs and I'm looking for a way to store such information in the issued CA certificate so my validation software can make use of it.

I care less if this is called capability or constraints, and more about the capacity to store such information.
If not standardized here, I think I will just create a private extension for this purpose, since I need it.

/Stefan

From: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
Date: Mon, 23 May 2011 15:10:46 -0400
To: Stefan Santesson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [pkix] Trust Constraints - Possible request for yet another certificate extension

Stefan,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Monday, May 23, 2011 6:15 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [pkix] Trust Constraints - Possible request for yet another certificate extension

All,

Example:

Thoughts?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 24 May 2011 00:03:10 +0200

Santosh,

In that case I think I go for capabilities, or even service information. I
think I like that better "Service Information extension", because it is
actually information about the service provided by that CA.

Anyone who do not understand the information is free to do what they want.
This is not supposed to change the laws of PKI, general path validation
rules applies.
I do not need to declare excluded and permitted. It would be quite possible
to define such statements though, but I don't need them. I just need
information about the service provided by each CA, and by the root.
Also I do not need to check persistence of the path, each CA certificate
service information stands for itself. The RP is free to draw any conclusion
it wishes from it.
It is not top down constraining = You are not allowed to trust this CA in
any other way than the one I say.
It is pure information = here is information about what is so. Choose for
yourself if this influences your trust decision.

What I mainly need to include is the TSL Trust Service Type declarations
defined in ETSI TS 102 231, such as:

http://uri.etsi.org/TrstSvc/Svctype/CA/PKC - A Certification authority
issuing public key certificates.
http://uri.etsi.org/TrstSvc/Svctype/CA/QC - A Certification authority
issuing Qualified Certificates.
http://uri.etsi.org/TrstSvc/Svctype/TSA - A Time stamping authority.
http://uri.etsi.org/TrstSvc/Svctype/Certstatus/OCSP - A Certificate status
provider operating an OCSP-server.
http://uri.etsi.org/TrstSvc/Svctype/Certstatus/CRL - A Certificate status
provider operating a CRL.

I would then carry these in an XML structure that defines the purpose of
including each declaration, like:
<ServicesByThisAuthority>
   <Service>http://uri.etsi.org/TrstSvc/Svctype/CA/QC</Service>
</ServicesByThisAuthority>

or
<ServicesUnderThisAuthority>
   <Service>http://uri.etsi.org/TrstSvc/Svctype/TSA</Service>
</ServicesUnderThisAuthority>

In a RootCA I could include:

<ServicesUnderThisAuthority>
   <Service>http://uri.etsi.org/TrstSvc/Svctype/CA/QC</Service>
   <Service>http://uri.etsi.org/TrstSvc/Svctype/Certstatus/OCSP</Service>
   <Service>http://uri.etsi.org/TrstSvc/Svctype/TSA</Service>
</ServicesUnderThisAuthority>

And then include the service information for each CA i Issue under this
root. This would allow me to:
- Not accept any other EE certificate type but qualified certificates under
this root, but
- Still allow validation of timestamps and OCSP responses under this root
under proper authorities.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Mon, 23 May 2011 15:53:44 -0400
To:  Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [pkix] Trust Constraints - Possible request for yet another
certificate extension

> You are also saying that the constraint¹s absence means that the CA can be
> used for any purpose.  Right?
>  
> 1.     This need not be in a root certificate.  It can be in root issued CA
> certificates unless you envision root to be direct issuer of end entity
> certificates
> 
> 3.     I suggest that the path validation logic honor the presence of this
> extension in downstream CAs a la name constraints
> 
> 4.     I suggest you think about what the relying party should do if it does
> not understand semantics of one of the OIDs present in the extension,
> especially in the excluded field.
> 
> TrustServiceType declaration carried for that CA in an EU Trust Service List.
> That tells me if that CA is used to support time stamping, OCSP, qualified
> certificates, regular EE certificates etc. This information about the service
> is lost when I cross certify these CAs and I'm looking for a way to store such
> information in the issued CA certificate so my validation software can make
> use of it.
> 
>  
> 
>> of the constraint OID. This way we would not have to bother with I18N stuff
>> in the extension definition. Clean and simple.
>> 
>>  
>>

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 23 May 2011 21:01:40 -0400

Hello Stephan,

if it is uri that you are thinking about, we could also extend PRQP to
include those extensions. This would provide flexibility and availability
for those URIs also for currently issued CAs...

Cheers,
Max

On 05/23/2011 06:03 PM, Stefan Santesson wrote:
> Santosh,
>
> In that case I think I go for capabilities, or even service information.
> I think I like that better "Service Information extension", because it
> is actually information about the service provided by that CA.
>
> Anyone who do not understand the information is free to do what they
> want. This is not supposed to change the laws of PKI, general path
> validation rules applies.
> I do not need to declare excluded and permitted. It would be quite
> possible to define such statements though, but I don't need them. I just
> need information about the service provided by each CA, and by the root.
> service information stands for itself. The RP is free to draw any
> conclusion it wishes from it.
> It is not top down constraining = You are not allowed to trust this CA
> in any other way than the one I say.
> It is pure information = here is information about what is so. Choose
> for yourself if this influences your trust decision.
>
> http://uri.etsi.org/TrstSvc/Svctype/Certstatus/OCSP - A Certificate
> status provider operating an OCSP-server.
> http://uri.etsi.org/TrstSvc/Svctype/Certstatus/CRL - A Certificate
> status provider operating a CRL.
>
> - Not accept any other EE certificate type but qualified certificates
> under this root, but
> - Still allow validation of timestamps and OCSP responses under this
> root under proper authorities.
>
> /Stefan

-- 

http://member.acm.org/~openca/

Massimiliano Pala, Ph.D.
Director, OpenCA Labs
Professor, NYU Poly

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 23 May 2011 18:11:02 -0700 (Pacific Daylight Time)

> that are accepted as valid.

Okay, but this doesn't explain why it has to be a self-limiting constraint.

You have a single cross-certifying root.  The Policies extension is the correct semantic place to convey those Policies through the various trust chains.  i.e., if a particular CA is only going to be used to issue Qualified Certificates, then the cross-certificate needs to contain only the Qualified Certificates policy.

You should look at PolicyMapping.

The appropriate way to handle this is to have a cross-certifying trust anchor with policies and mappings in the cross-certifications.  They relate to the interpretation of the entire chain, not merely the end entity.  The cross-certified CA does not need to have any knowledge of the cross-certifier, and you're trying to convey an authority limitation upon the certificates which a given CA can issue; both of these point to Policies as the correct place for the Authority of your policy to be conveyed.

It is actually legitimate for a given CA certificate to chain validly but to be trusted for no purposes.  This doesn't invalidate the identity of the holder of that key (the operator of the CA), which is what is actually certified.  Thus, the intermediate CA certificate may be validly chained to a trust anchor but not have any policies or assertions which can be proven to your software by it.

Just create a policy OID that maps to a technical policy of "always invalid", and map the policies which the offending CA issues to that.

-Kyle H

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 24 May 2011 08:05:04 +0200

Kyle,

On 11-05-24 3:11 AM, "Kyle Hamilton" <[email-masked]> wrote:

>You have a single cross-certifying root.  The Policies extension is the
>correct semantic place to convey those Policies through the various trust
>chains.  i.e., if a particular CA is only going to be used to issue
>Qualified Certificates, then the cross-certificate needs to contain only
>the Qualified Certificates policy.

No this does not work. When I cross certify I have no clue what policy the
cross-certified CA will use when issuing end-entity certs.
I wish so that certificate policies was correctly implemented out there,
but it is in fact terribly, terribly broken. About 50% of CAs out there in
the EU PKIs include policy OIDs in CA certificates that defines the policy
under which the CA operates, and not the policy they use to issue end
certs, so the policy in the CA cert does not tell me what policy they
include in the certs they issue.

Also, I have no way to tell which policy OID used out there that
corresponds to qualified certificates. I can't keep track of 500 trust
services and figure out what OIDs they use and what they mean.

However, I do know their service declaration in the national Trust-service
List they are listed in, and I know that they MUST include a QC-statement
extension in their qualified certificate, so ignoring the cert policy
makes this all implementable.

>The appropriate way to handle this is to have a cross-certifying trust
>anchor with policies and mappings in the cross-certifications.  They
>relate to the interpretation of the entire chain, not merely the end
>entity.  The cross-certified CA does not need to have any knowledge of
>the cross-certifier, and you're trying to convey an authority limitation
>upon the certificates which a given CA can issue; both of these point to
>Policies as the correct place for the Authority of your policy to be
>conveyed.
>
>It is actually legitimate for a given CA certificate to chain validly but
>to be trusted for no purposes.  This doesn't invalidate the identity of
>the holder of that key (the operator of the CA), which is what is
>actually certified.  Thus, the intermediate CA certificate may be validly
>chained to a trust anchor but not have any policies or assertions which
>can be proven to your software by it.
>
>Just create a policy OID that maps to a technical policy of "always
>invalid", and map the policies which the offending CA issues to that.

Again, I really wish certificate policies wasn't broken in todays
implementations, and that CAs used consistent policies.

Since I have control over both the code that cross certifies, and the code
that validates signatures based on the cross certification, I will use
some kind of serviceInfo extension to do the job. The question is just
whether it should be standardized.

If it is standardized, I would prefer to define the extension in PKIX and
then standardize infoStatements related to EU Trust Service lists in ETSI
based on the PKIX extension.

/Stefan

>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 May 2011 07:32:09 -0400

Stefan,

It seems that this is not something infrastructure telling you.  It seems relying party decision.  In that case, it may be better to let the relying party associate with the certificates like Microsoft does in CAPI store.

If you think this is something from a CA to relying parties, albeit advisory, then adding a richer extension with what I am permitting and what I am not permitting and let the relying party use the information from any or all CAs in the path a more versatile solution that what you are saying.  Since what I am saying helps implement your requirement also, it is better to have a standard that is broader.

From: Stefan Santesson [mailto:[email-masked]]
Sent: Monday, May 23, 2011 6:03 PM
To: Santosh Chokhani; [email-masked]
Subject: Re: [pkix] Trust Constraints - Possible request for yet another certificate extension

Santosh,

In that case I think I go for capabilities, or even service information. I think I like that better "Service Information extension", because it is actually information about the service provided by that CA.

Anyone who do not understand the information is free to do what they want. This is not supposed to change the laws of PKI, general path validation rules applies.
I do not need to declare excluded and permitted. It would be quite possible to define such statements though, but I don't need them. I just need information about the service provided by each CA, and by the root.
Also I do not need to check persistence of the path, each CA certificate service information stands for itself. The RP is free to draw any conclusion it wishes from it.
It is not top down constraining = You are not allowed to trust this CA in any other way than the one I say.
It is pure information = here is information about what is so. Choose for yourself if this influences your trust decision.

What I mainly need to include is the TSL Trust Service Type declarations defined in ETSI TS 102 231, such as:

http://uri.etsi.org/TrstSvc/Svctype/CA/PKC - A Certification authority issuing public key certificates.
http://uri.etsi.org/TrstSvc/Svctype/CA/QC - A Certification authority issuing Qualified Certificates.
http://uri.etsi.org/TrstSvc/Svctype/TSA - A Time stamping authority.
http://uri.etsi.org/TrstSvc/Svctype/Certstatus/OCSP - A Certificate status provider operating an OCSP-server.
http://uri.etsi.org/TrstSvc/Svctype/Certstatus/CRL - A Certificate status provider operating a CRL.

I would then carry these in an XML structure that defines the purpose of including each declaration, like:
<ServicesByThisAuthority>
   <Service>http://uri.etsi.org/TrstSvc/Svctype/CA/QC</Service>
</ServicesByThisAuthority>

or

And then include the service information for each CA i Issue under this root. This would allow me to:
- Not accept any other EE certificate type but qualified certificates under this root, but
- Still allow validation of timestamps and OCSP responses under this root under proper authorities.

/Stefan

Stefan,

You miss the point.

To: Santosh Chokhani; [email-masked]<mailto:[email-masked]>

/Stefan

Stefan,

All,

Example:

Thoughts?

/Stefan

_______________________________________________ pkix mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 May 2011 14:45:27 +0200

I think I have come up with a better solution than the extension I was
considering.

I could just define a SIA accessMethod OID and accessLocation to point at a
signed file containing the information about the CA service I want to make
available.
So all I need is to define my own accessMethod OID. This is a lot simpler
for me to implement than a new extension.

And it is safe, since those who do not understand it will just safely ignore
it.

Thus, I do not propose definition of any new extension.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Tue, 24 May 2011 07:32:09 -0400
To:  Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [pkix] Trust Constraints - Possible request for yet another
certificate extension

> Stefan,
>  
> It seems that this is not something infrastructure telling you.  It seems
> relying party decision.  In that case, it may be better to let the relying
> party associate with the certificates like Microsoft does in CAPI store.
>  
> If you think this is something from a CA to relying parties, albeit advisory,
> then adding a richer extension with what I am permitting and what I am not
> permitting and let the relying party use the information from any or all CAs
> in the path a more versatile solution that what you are saying.  Since what I
> am saying helps implement your requirement also, it is better to have a
> standard that is broader.
>  
> 
> This is not supposed to change the laws of PKI, general path validation rules
> applies.
> 
> I do not need to declare excluded and permitted. It would be quite possible to
> define such statements though, but I don't need them. I just need information
> about the service provided by each CA, and by the root.
> 
>> What you are saying is that if the constraint is present, then the CA can
>> only be used for the listed purposes.  Right?
>>  
>> is lost when I cross certify these CAs and I'm looking for a way to store
>> such information in the issued CA certificate so my validation software can
>> make use of it.
>> 
>>  
>>