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

["Santosh Chokhani" <[e-mail]>]

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