At 6:51 PM -0800 1/5/09, Julien R Pierre - Sun Microsystems wrote:
>Paul,
>
>Paul Hoffman wrote:
>
>>>3) A corollary of (2): Even when parent == grandparent, and hence parent
>>>is also a sibling, it's not generally true that you can use the OCSP URL
>>>from the parent to check the OCSP status of a child.
>>
>>All of that is true (and is true for CRLs, I believe), but it is not what I
>>was speaking to. The recent MD5 attack creates a rogue sub-CA, that is a new
>>child of one of your trust anchors. The Microsoft article made it sound (to
>>me, at least) that if the rogue sub-CA (the child) has a AIA, then IE will
>>not look in the parent's AIA to determine the status of the child. If that's
>>true, it is broken.
>
> >Each level of the family can have its own AIA that applies to all of its
> >children, not just to end entities.
>
>The last sentence is what I believe Nelson was disputing.
>
>As far as I know, the AIA only applies to the end entity certificate, and not
>to any children certificates. Do you have any evidence in any standard that
>this is not the case ?
>
>From RFC3280 :
>
>4.2.2.1 Authority Information Access
>
> The authority information access extension indicates how to access CA
> information and services for the issuer of the certificate in which
> the extension appears.
>
>In other words, if you examine the AIA of an intermediate certificate, you
>will access the services of the intermediate's issuer (perhaps the root). You
>would not be able to use the OCSP responder to check the EE certificate's
>revocation status.
My reading of RFC 5280 (the successor to RFC 3280, but it's almost identical
here) is that an AIA can tell you the OCSP responder for a particular CA or RA.
The OCSP responder is definitive for any certs signed by the CA/RA. In the case
of a rogue RA, the OCSP responder for the CA can revoke the rogue RA because
the rogue RA is "signed" by the CA.
Is there part of 3280/5280 that you see that disagrees with this? This is a
serious question: I could be way off on this.
>It seems to me also that a self-signed certificate marked as a trust anchor,
>ie. a root, probably shouldn't have an AIA extension.
Wait. No kind of certificate is marked as a trust anchor. I assume you probably
me "root" as in a self-signed cert with the CA bit turned on.
>At least it wouldn't make much sense for it to point to any OCSP responder,
>since the root cannot revoke itself - there is no one above the root to revoke
>it.
Correct, but don't forget that the AIA has two uses. It is quite reasonable for
a root to have an AIA extension with id-ad-caIssuers.
>>>4) Trust anchors are not necessarily roots.
>>
>>Of course. I'm not seeing where that is relevant here, but I could be missing
>>something.
>>
>>>5) Most roots don't have AIA cert extensions. Only 8 out of the 125 roots
>>>in nssckbi have them.
>>
>>Now *that* is sad. I was hoping for closer to 50%. It does not make my
>>argument wrong, just pretty moot.
>
>No, I think the 8 are probably an anomaly. I wonder why they have it at all.
See above.
>Perhaps these are not really roots .
Tell that to VeriSign. Here is the dump of the extensions take from their cert
taken from the Firefox root pile:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
F1:5A:89:93:55:47:4B:BA:51:F5:4E:E0:CB:16:55:F4:D7:CC:38:67
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.6
CPS: https://www.verisign.com/rpa
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication,
Netscape Server Gated Crypto, Microsoft Server Gated Crypto
X509v3 Authority Key Identifier:
keyid:4E:43:C8:1D:76:EF:37:53:7A:4F:F2:58:6F:94:F3:38:E2:D5:BD:DF
Authority Information Access:
OCSP - URI:http://EVIntl-ocsp.verisign.com
CA Issuers - URI:http://EVIntl-aia.verisign.com/EVIntl2006.cer
1.3.6.1.5.5.7.1.12:
0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
