Subject: Re: [pkix] Cross-cert as anchor (was Re: AD Review ofdraft-ietf-pkix-rfc5280-clarifications-03.txt)

From: Tom Gindin <[email-masked]>
Date: Sun, 2 Oct 2011 19:31:12 -0400

The trust anchor information defined in RFC 5280 6.1.1-d-1 
includes the DN of the first certificate in the chain, but not the DN of 
the issuer.  The process of using a CA certificate as a trust anchor drops 
those fields which distinguish a self-signed certificate from an ordinary 
cross-certificate, so there seems little reason to accept one type as an 
anchor but not the other.  There is also no requirement that only 
self-signed certificates be used as a certificate within CertPathControls 
in RFC 5914 section 2.5.  Further comments marked as [TG].

Tom Gindin

From:   "David A. Cooper" <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS
Cc:     PKIX <[email-masked]>
Date:   09/28/2011 10:42 AM
Subject:        Re: Cross-cert as anchor (was Re: [pkix] AD Review 
ofdraft-ietf-pkix-rfc5280-clarifications-03.txt)

On 09/27/2011 09:13 PM, Tom Gindin wrote:
>          The issuer of the cross-certificate is clearly NOT the trust
> anchor in the first scenario.  If it were, the RP would trust paths
> originating at that issuer through any of its many cross-certificates
> instead of only those using the trusted cross-certificate.

The X.509 path validation algorithm simply takes a trust anchor, a 
prospective certification path, and other information, and provides a 
valid/not valid response (or at least that's a slightly simplified 
version of how it works).  There is nothing that says that if you choose 
to use a particular trust anchor when validating one particular 
prospective certification path that you must accept any certification 
path that can be validated using that same trust anchor.  So, any claim 
that the issuer of a certificate cannot have been used as a trust anchor 
when validating one prospective certification path because you would be 
unwilling to use that same trust anchor to validate other prospective 
certification paths simply demonstrates a misunderstanding of the 
standard.

[TG] I know that RFC 5280 section 6.1 permits an application to limit the 
set of paths beyond what passes basic certificate processing by 
"augmenting the algorithm".  However, an implementation of basic 
certificate processing using the issuer of the cross certificate as an 
anchor will accept all paths whose first certificate is a 
cross-certificate from that issuer unless they fail other criteria, so 
most implementations will accept them although it's possible to augment 
the algorithm in such a way as to reject them.

> I am not
> requiring that the cross-certificates in question be checked for
> revocation or even verified, so they aren't part of the path.

So what you are proposing is that the certificate from which you extract 
the trust anchor information is not actually processed as the first 
certificate in the path, as others are arguing should be done with the 
certificate from which trust anchor information is extracted.   Rather 
you are suggesting that the relying party should be free to impose 
constraints on the set of certification paths that it will accept from a 
given trust anchor.  I don't think anyone has argued against that.  That 
is why the path validation algorithm allows for inputs such as 
initial-permitted-subtrees to be specified.  But, the values of these 
inputs are specified by the relying party, not by the trust anchor.  The 
trust anchor imposes constraints by (1) not issuing certificates that 
violate its own self-imposed constraints and (2) including appropriate 
constraints extensions in an cross-certificates that it issues.

[TG] I am proposing that the RP can adopt constraints on an anchor which 
were originally defined by another entity which issued a cross-certificate 
for that anchor.  While the RP is free to impose any constraints it 
wishes, many RP's support more than a few issuers and might appreciate a 
means of delegating the definition of those constraints. 

> It's only more logical to regard the issuer of the cross certificate as 
the anchor
> if you are committed to the idea that the only certificates which should
> be used as anchors are self-signed.  TrustAnchorInfo in RFC 5914 section 
2
> has no analogue of the issuer field or the certificate signature, so
> whether a certificate is self-signed or a cross-certificate has no 
effect
> on whether it's a valid source for that information.

Not true at all.  It is perfectly reasonable to regard the issue of the 
cross-certificate as the trust anchor if you intend to process the 
cross-certificate as if it were the first certificate in the prospective 
certification path in order to process any constraints extensions in the 
certificate.

[TG]    It's at least equally reasonable to treat constraints extensions 
in such a certificate as part of the anchor definition instead.

>          Trust anchors are decided on by the RP, and whether the issuer 
of
> a CA certificate intended it to be used as an anchor does not bind him. 
We
> can assume that a self-signed CA certificate was intended for use by 
RP's
> as an anchor, but I see no reason why a cross-certificate cannot also be
> used as an anchor.

It can, and I never argued otherwise.  But, if you decide to process 
this extension in order to honor any constraints extensions that it has, 
then this cross-certificate is the first certificate in the 
certification path and the issuer of the certificate is the trust 
anchor.  The subject of the cross-certificate is only the trust anchor 
if that subject issued the first certificate in the prospective 
certification path, and in that case, since the relying party gets to 
select the values for the path validation inputs, it is up to the 
relying party to decide whether its wants to consider the information in 
the cross-certificate when it decides what values to use for the path 
validation inputs.

[TG]    I'm not arguing that you should process the cross certificate as 
the first certificate in the path.  I'm arguing that you should extract 
the constraints from it using the same mappings as in RFC 5914 section 
2.5.

> From:   "David A. Cooper"<[email-masked]>
> To:     Tom Gindin/Watson/IBM@IBMUS
> Cc:     PKIX<[email-masked]>
> Date:   09/27/2011 11:09 AM
> Subject:        Re: [pkix] AD Review
> ofdraft-ietf-pkix-rfc5280-clarifications-03.txt
>
>
>
> Perhaps I am misunderstanding, but I don't see how your examples differ
> from ordinary path validation, except in the way that you describe them.
>
> There are a couple of ways to look at your examples.  In the first
> scenario, the most logical view seems to be that the issuer of the
> cross-certificate is the trust anchor and the cross-certificate is the
> first certificate in the prospective certification path.
>
> In the second scenario, the RP creates its own CA, which it uses as a
> trust anchor, and the certificates that it issues to the "national root
> CA's" are the first certificates in any prospective certification
> paths.  The second scenario could also be accomplished with the RP
> establishing a CA and issuing cross-certificates if the RP simply
> associated appropriate constraints with each of the national root CAs
> and used those constraints as inputs to the path validation algorithm.
>
> It seems that only be viewing these scenarios in an unusual manner
> (i.e., calling the subject of the first (non-self-signed) certificate in
> the path the trust anchor even though you want that certificate to be
> included as part of the of the prospective certification path).
>
> Neither of these examples, however, involve a CA issuing a self-signed
> certificate that includes constraints extensions, with the expectation
> that relying parties will enforce those constraints, and then
> intentionally issuing certificates that violate those constraints.
>
> On 09/26/2011 08:46 PM, Tom Gindin wrote:
>>           I think it's legitimate for an intermediate CA certificate to 
be
>> used as a trust anchor, and for the RP to honor the constraint 
extensions.
>>    Given that, why should name constraints or policy constraints in a
>> self-signed certificate not be honored?
>>           The cases I envision accept a trust anchor in the form an 
ordinary
>> cross-certificate, at least in appearance.  I see two scenarios where 
this
>> can be valuable.  In the first scenario, an extranet application trusts 
a
>> set of corporate CA's by trusting their cross-certificates and enforces
>> name constraints on them.  That application does NOT accept public
>> certificates from the CA's which issued the corporate CA's 
certificates,
>> nor certificates from all of the organizations which those CA's have
>> cross-certified.  It simply trusts the corporate CA's on its list.
>>           In the second scenario, a distributor of RP software 
distributes
>> trust anchors as certificates as many such packages do.  It wishes to
>> enforce on many national root CA's a constraint that each may issue
>> certificates containing only certain country codes in DNS names or in
>> DN's, and may not issue certificates covering the global TLD's, while
>> accepting their certificates for their own countries.  It creates a
>> certificate for that CA with such a name constraint and an issuer
>> representing the RP itself.  This certificate will not be self-signed, 
as
>> the distributor is imposing the name constraint rather than the 
national
>> root CA itself.  Is something wrong with this scenario?
>>           Constraints are always enforced as limitations on what a 
relying
>> party will accept, and I don't see how that differs between a trust 
anchor
>> and an intermediate CA.  We need not imply that a CA which exceeds its
>> published constraints is thereby acting improperly to reject the 
exceeding
>> certificates, and thus I don't see that the points in your second
>> paragraph are relevant to implementations.