On 2/13/2009 11:52 AM, Eddy Nigg wrote:
> On 02/13/2009 09:36 PM, Ben Bucksch:
>> FWIW, this is irrelevant. *We* require the ETSI. We can also require
>> additional requirements, like that the CPS is published.
>>
>>> or you have to add a new policy or practices point which says that
>>> regardless
Nelson B Bolyard wrote:
Here is some info that should help with understanding all this.
Thanks, this is very useful. So to sum up my understanding:
If NSS had support for CRL DP, but no support for CIDP, then what would
happen with Hongkong Post (assuming no changes to its current practices,
Frank Hecker wrote, On 2009-02-20 11:15:
> Frank Hecker wrote:
>> Option 4: Hongkong Post makes no changes to either its CRLs or its end
>> entity certs, and NSS ignores partitioned CRLs encountered in CRL DP
>> processing. In this option Hongkong Post would make no changes
>> whatsoever to its
Frank Hecker wrote:
Option 4: Hongkong Post makes no changes to either its CRLs or its end
entity certs, and NSS ignores partitioned CRLs encountered in CRL DP
processing. In this option Hongkong Post would make no changes
whatsoever to its current practices. NSS would fetch the partitioned CRL
Nelson B Bolyard wrote:
I understand your question to be relating the way FF works today, and
NOT to the way it will/might work when CrlDP extension processing causes
automatic CRL fetches.
Yes, that's correct. My question was with respect to the current
situation, i.e., if we were to approve
Benjamin Smedberg wrote, On 2009-02-20 10:28:
> On 2/20/09 12:11 PM, Nelson B Bolyard wrote:
>> Benjamin Smedberg wrote, On 2009-02-19 07:39:
>>
>>> It sounds to me that we could and should fix this bug simply by disabling
>>> punycode for the wildcard portion.
>> I'm not sure what you're proposing
On 02/20/2009 08:28 PM, Benjamin Smedberg:
I don't see how the attack could have been done without wildcards. CA
guidelines say that certificates should not be issued with homographic
characters that might cause confusion, and as far as we know these
guidelines are being followed. The attack here
On 2/20/09 12:11 PM, Nelson B Bolyard wrote:
> Benjamin Smedberg wrote, On 2009-02-19 07:39:
>
>> It sounds to me that we could and should fix this bug simply by disabling
>> punycode for the wildcard portion.
>
> I'm not sure what you're proposing here, Ben, or what effect you think
> it would h
Jean-Marc Desperrier wrote:
Frank Hecker wrote:
[...] Am I right that someone
who wished to check revocation status on EE certs in Firefox could just
download the full CRL and use that? [...]
The right word is indeed *could*.
The address of that CRL *does not* appear inside the certificate, a
Benjamin Smedberg wrote, On 2009-02-19 07:39:
> It sounds to me that we could and should fix this bug simply by disabling
> punycode for the wildcard portion.
I'm not sure what you're proposing here, Ben, or what effect you think
it would have.
Homomorphic characters aren't a problem for wildcar
Frank Hecker wrote, On 2009-02-19 06:26:
> Jean-Marc Desperrier wrote:
>> The content of the IssuingDistributionPoint is in fact perfectly
>> correct, pointing to
>> http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL2.crl just like does the
>> cRLDistributionPoints in the cert itself.
>
> Thank yo
Eddy Nigg wrote:
On 02/19/2009 03:30 PM, Jean-Marc Desperrier:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
.cn is authorized
On 18/2/09 23:05, Frank Hecker wrote:
Paul Hoffman wrote:
A Mozilla policy that says "we allow trust anchors for which we cannot
do revocation checking" seems wrong.
Well, yes, but as Eddy pointed out for the past 10+ years we've had a
policy that basically amounted to the same thing, at lea
Frank Hecker wrote:
[...] Am I right that someone
who wished to check revocation status on EE certs in Firefox could just
download the full CRL and use that? [...]
The right word is indeed *could*.
The address of that CRL *does not* appear inside the certificate, and
the adresse of the the CR
14 matches
Mail list logo
