Eddy Nigg wrote:
Shouldn't have been there an announcement for bug 371362 or shall we
simply follow the schedule? I guess a summary from you would be in any
case useful as you've done with Microsec. Please advice...
Sorry, there wasn't an announcement because I was too busy with other
stuff
Eddy Nigg wrote:
On 10/10/2008 01:45 PM, Ian G:
Finally, if it ever did get to court, I don't see any good reasons
why it would not stand up?
Well, I prefer to refrain from commenting on this, but the fact that I
mentioned it could give you some hint ;-)
Sounds a bit like the
It is conformant IF and only IF the user (not the CA) chooses to trust
that responder. If the CERTIFICATE issued by the issuer says to go to
that responder for OCSP, but the responder's cert is not either
a) the the issuer's cert, or
b) a cert issued by the same issuer as the cert under
István Zsolt BERTA:
It is conformant IF and only IF the user (not the CA) chooses to trust
that responder. If the CERTIFICATE issued by the issuer says to go to
that responder for OCSP, but the responder's cert is not either
a) the the issuer's cert, or
b) a cert issued by the same issuer as
Eddy Nigg:
Except if Nelson thinks otherwise, removing the AIA OCSP service URI
solves this issue. More specific the Mozilla CA Policy calls for:
cRLDistributionPoints or OCSP authorityInfoAccess extensions for which
no operational CRL or OCSP service exists.
Therefor the OCSP reference
Eddy Nigg:
I think we have a problem here! I wanted to make sure that the CA root
and intermediate CA certificates don't include OCSP AIA extensions and I
noticed the following when importing and examining the CA root...
- The CA root includes the OCSP service URI in the AIA extension:
Ian G:
One good way to achieve certainty is for Mozilla to require the
documents to be declared in the process.
That might be a good idea...actually that's what I assume when a CA
makes a request for inclusion (but on the other hand, no CA has yet
confirmed or signed an agreement in this
7 matches
Mail list logo
