RE: RFC 3280 bug? - Special processing for self issued certificates

["Stefan Santesson" <[e-mail]>]

Santosh,

Yes that's true. That was not my question though :-) 

The question is: If we have an exception not to inhibit anyPolicy for
self issued certificates, since it only passes the policies from its
parent certificate, then why do we need to enforce inhibit anyPolicy
just because the self-issued certificate is last in a path.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 30 augusti 2004 22:45
> To: [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> Stefan:
> 
> For inhibit any policy, when you define skip certs, you want to
enforce
> the
> constraints on a specific CA down stream from you regardless of
whether
> the
> path is from your current certificate or from a current to roll over
> certificate.  Thus, skip certs for inhibit policy should not count
> self-issued certificates.
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Monday, August 30, 2004 12:42 PM
> To: Steve Hanna
> Cc: Sharon Boeyen; [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> 
> Thanks Steve,
> 
> Yes, this is a valid technical argument.
> I suppose it is reasonable to accept a certificate as a key rollover
cert
> despite name constraints violations in subjAltName while you wouldn't
> accept
> those violations if the same certificate was used as an EE cert to
> validate
> e.g. a new name constraints violating e-mail address of that CA.
> 
> It seems harder however to transfer this logic to inhibit anyPolicy.
Any
> ideas/arguments there?
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Steve Hanna
> > Sent: den 30 augusti 2004 17:07
> > To: Stefan Santesson
> > Cc: Sharon Boeyen; [e-mail]
> > Subject: Re: RFC 3280 bug? - Special processing for self issued
> > certificates
> >
> >
> > Stefan,
> >
> > You wrote:
> >  > For all valid paths to a self-issued certificate, the self-issued
> cert
> >  > will be preceded by a valid intermediary CA certificate with a  >
> > matching subject name. Lets call that the ICA cert.  >
> >  > It seams reasonable to me that that IF ICA has a valid subject
name
> >  > then that name would be OK also for the rollover cert, regardless
> of
> >  > whether it is used as an intermediary cert or validated as target
> > > cert.
> >
> > I will admit I had to check the archives on this one.
> > Your argument seemed compelling at first. But the email
> > below explains the problem. In a nutshell, the self-issued
certificate
> > can contain a *subjectAltName* that is not permitted by the name
> > constraints and not contained in the ICA cert.
> >
> > I hope that explains why this requirement is needed.
> >
> > Thanks,
> >
> > Steve
> >
> > -------- Original Message --------
> > Date: Fri, 04 May 2001 12:44:34 -0400
> > From: Steve Hanna <[e-mail]>
> > To: PKIX List <[e-mail]>
> > Subject: Ignoring name constraints with self-issued certs
> >
> > Regretfully, I must raise another issue with son-of-2459. In section
> > 4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:
> >
> >     Name constraints are not applied to certificates whose issuer
and
> >     subject are identical.  (This could prevent CAs that use name
> >     constraints from issuing self-signed certificates to implement
key
> >     rollover.)
> >
> > This statement is consistent with the validation algorithm in
section
> > 6.1, which says:
> >
> >     A certificate is termed self-issued if the DNs that appear in
the
> >     subject and issuer fields are identical and are not empty.  In
> >     general, the issuer and subject of the certificates that make up
a
> >     path are different for each certificate.  However, a CA may
issue
> a
> >     certificate to itself to support key rollover or changes in
> >     certificate policies.  These self-issued certificates are not
> >     counted when evaluating path length or name constraints.
> >
> > However, these statements (and the corresponding text in the
> validation
> > algorithm, steps (b) and (c) of section 6.1.3) are not consistent
with
> > the text in X.509(2000), which says (in step g of section 10.5.1)
"If
> > the certificate is not an intermediate self-issued certificate,
check
> > that the subject name is within the name-space given by the value of
> > permitted-subtrees and is not within the name-space given by the
value
> > of excluded-subtrees."
> >
> > Note the word *intermediate* in X.509(2000). If a self-issued
> > certificate is the last certificate in the path, the name
constraints
> > check MUST be performed. Otherwise, a security hole is opened up.
> > Consider the following chain of 2 certificates:
> >
> > Certificate 1:
> >   Issuer:  o=trusty, c=us
> >   Subject: o=shady, c=us
> >   Basic Constraints:
> >    cA=true
> >   Name Constraints:
> >    Permitted:
> >     directoryName: o=shady, c=us
> >     rfc822Name: .shady.com
> >
> > Certificate 2:
> >   Issuer:  o=shady, c=us
> >   Subject: o=shady, c=us
> >   SubjectAltNames:
> >    rfc822Name: [e-mail]
> >
> > If o=trusty, c=us is one of the trust anchors (and the certificate
> > signatures verify), this chain is valid according to son-of-2459. It
> is
> > not valid according to X.509(2000). I think you will agree that the
> > behavior described in X.509(2000) is correct. Otherwise, self-issued
> > certificates can be used to completely bypass the effects of name
> > constraints.
> >
> > Therefore, I suggest that section 4.2.1.11 of
> > draft-ietf-pkix-new-part1-06.txt be modified to say:
> >
> >     Name constraints are not applied to certificates whose issuer
and
> >     subject are identical (unless the certificate is the final
> >     certificate in the path).  (This could prevent CAs that use name
> >     constraints from issuing self-signed certificates to implement
key
> >     rollover.)
> >
> > We should also modify the last sentence of the paragraph in section
> 6.1
> > that begins "A certificate is termed self-issued ..." (listed in
full
> > above) to "These self-issued certificates are not counted when
> > evaluating path length. Name constraints are only applied to a
> > self-issued certificate if it is the final certificate in the path."
> >
> > I also suggest that the start of steps (b) and (c) in section 6.1.3
be
> > changed to read:
> >
> >        (b) If certificate i is self-issued and it is not the final
> >        certificate in the path, skip this step for certificate i.
> >        Otherwise, verify that the subject name is within one of the
> >        permitted_subtrees for X.500 distinguished names, and verify
> >        that each of the alternative names in the subjectAltName
> >        extension (critical or non-critical) is within one of the
> >        permitted_subtrees for that name type.
> >
> >        (c) If certificate i is self-issued and it is not the final
> >        certificate in the path, skip this step for certificate i.
> >        Otherwise, verify that the subject name is not within one of
> the
> >        excluded_subtrees for X.500 distinguished names, and verify
> that
> >        each of the alternative names in the subjectAltName extension
> >        (critical or non-critical) is not within one of the
> >        excluded_subtrees for that name type.
> >
> > Comments?
> >
> > Steve
> 
>