Paul,
Paul Hoffman wrote:
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 tur
Is there any way I can suck back the last two messages I sent on this thread
and pretend they never happened? I guess not.
Please ignore my assertions about what the AIA extension does: I was completely
wrong. As we were making the AIA extension in the PKIX WG, we discussed
multiple proposals,
On 6/1/09 04:01, Eddy Nigg wrote:
On 01/06/2009 04:51 AM, Julien R Pierre - Sun Microsystems:
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. At least
it wouldn't make much sense for it to point to any OCSP respon
Looking at the http://www.win.tue.nl/hashclash/rogue-ca/ attack
specifically...
The "Equifax Secure Global eBusiness CA-1" self-signed Root Certificate trust
anchor does *not* contain the Authority Info Access extension or CRL
Distribution Points extension.
The Rogue CA Certificate does *not* c
On Mon, Jan 5, 2009 at 8:14 PM, Paul Hoffman wrote:
>>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 Acce
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
On 01/06/2009 04:51 AM, Julien R Pierre - Sun Microsystems:
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. At least
it wouldn't make much sense for it to point to any OCSP responder, since
the root cannot revoke i
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
At 4:01 PM -0800 1/5/09, Nelson B Bolyard wrote:
>Paul Hoffman wrote, On 2009-01-05 08:54:
>> At 3:09 PM +0100 1/5/09, Ian G wrote:
>
>>> [...] Hence, once we rogue-players have created a certificate like this,
>>> the CA cannot revoke it using its own control mechanisms. [...]
>
>> I am not convi
Paul Hoffman wrote, On 2009-01-05 08:54:
> At 3:09 PM +0100 1/5/09, Ian G wrote:
>> [...] Hence, once we rogue-players have created a certificate like this,
>> the CA cannot revoke it using its own control mechanisms. [...]
> I am not convinced the article is correct. If it is correct, it is a
Ian G wrote, On 2009-01-05 06:09:
> The recent MD5 collision attack has also demonstrated a "brittle" side
> of OCSP [1]:
I wouldn't call it an attribute of OCSP any more than it is an attribute
of revocation in general. The same thing is true for CRLs that is true
for OCSP. The relying party l
At 3:09 PM +0100 1/5/09, Ian G wrote:
>The recent MD5 collision attack has also demonstrated a "brittle" side of OCSP
>[1]:
>
>http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx
>
>It seems that, assuming we can create an intermediate or subroot certi
The recent MD5 collision attack has also demonstrated a "brittle" side
of OCSP [1]:
http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx
It seems that, assuming we can create an intermediate or subroot
certificate, then we can also redirect the OCSP
13 matches
Mail list logo
