On Tue, Feb 24, 2009 at 4:53 PM, wrote:
> It is possible that at some point in the future certificates chaining
> up to this root will no longer work with Firefox and other Mozilla-
> based products. Since Mozilla has no commitment at this time to
> support partitioned CRLs, it would be the respo
To summarize this discussion, only one concern has been raised in
regards to this request. In particular, Hongkong Post issues both a
full CRL and a partitioned CRL. Currently Firefox handles full CRLs,
but not partitioned CRLs. The end-entity certs chaining up to this
root include a cRLDistributio
Kaspar Brand wrote re RFC 5280:
Note that it refers to the DistributionPoint*Name*, not the
DistributionPoint itself - i.e. the CDP extension of a certificate can
certainly include multiple HTTP URIs (all pointing to the same CRL).
FWIW, here's the definition from RFC 5280, which might help in
Frank Hecker wrote:
> I understand your concern. Both RFC 3280 and RFC 5280 clearly allow for
> multiple names to be listed with the CRL DP extension; however they also
> say that
>
>If the DistributionPointName contains multiple values, each name
>describes a different mechanism to obta
On 02/24/2009 01:54 PM, Frank Hecker:
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain *the same CRL*.
...or use the same mechanism in order to balance and/or have a backup CRLDP.
It would be the responsibility of Hongkong Post
to chan
ma...@e-mice.net wrote:
Hongkong Post is seriously looking into this suggestion right now.
However, I can imagine that the decision will be very tough because,
you know, traditionally revocation checking is done by the application
developer or none. I have doubt whether most of application develo
Kyle Hamilton wrote:
How did the language in 5280 change the behavior of critical CRL
extensions?
Briefly, RFC 5280 allows (and implicitly endorses) a scenario where the
implementation might not fully support a critical CIDP extension and all
that it entailed (i.e., handling partitioned CRLs
On Feb 24, 7:57 am, Frank Hecker wrote:
> Nelson B Bolyard wrote:
> > 1. As you may know, the EV spec says that a client should not give a
> > cert the full EV treatment unless/until it has done some successful
> > revocation check (CRL or OCSP, this year) at least on the EE cert.
> > Beginning wi
Kyle Hamilton wrote:
So. If I understand correctly:
1) HKP issued certs currently do not cause problems.
2) HKP has been notified how their system may cause problems in the future.
3) HKP is not requesting EV status, so any EV-specific discussion is
irrelevant at this time.
4) HKP meets all o
Okay, meta-discussion here...
My understanding is that:
If an extension is marked critical, and an implementation does not
understand it, it MUST stop processing the certificate or CRL.
If an extension is NOT marked critical, and an implementation does not
understand it, it MAY stop processing th
Kyle Hamilton wrote, On 2009-02-23 20:19:
> There is only one last question that I'm going to ask, since it is
> relevant here: Which version of PKIX (3280 or 5280) does HKP issue
> certificates to be conformant to? My understanding is that NSS supports
> 3280 (and not 5280); if there are certi
So. If I understand correctly:
(I'll abbreviate Hongkong Post as HKP)
1) HKP issued certs currently do not cause problems.
2) HKP has been notified how their system may cause problems in the future.
3) HKP is not requesting EV status, so any EV-specific discussion is
irrelevant at this time.
4)
Nelson B Bolyard wrote:
Frank Hecker wrote, On 2009-02-20 16:53:
"However, implementations that do not support this extension MUST
either treat the status of any certificate *not listed on this CRL*
as unknown or locate another CRL that does not contain any
unrecognized critic
Frank Hecker wrote, On 2009-02-20 16:53:
> 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
Nelson B Bolyard wrote:
1. As you may know, the EV spec says that a client should not give a
cert the full EV treatment unless/until it has done some successful
revocation check (CRL or OCSP, this year) at least on the EE cert.
Beginning with FF 3.1 (IINM) FF will enforce that rule. This will
me
On Mon, Feb 23, 2009 at 11:30 AM, Frank Hecker
wrote:
> I can't speak for the NSS developers, however speaking personally I see no
> reason to drop support for manual import of CRLs.
Does the CRL processing:
1) handle the notAfter date properly?
2) throw an error when the imported CRL is evaluat
Frank Hecker wrote, On 2009-02-23 14:42 PST:
> Based on the discussion so far, my understand is as follows: In the near
> term Hongkong Post's certificates will work OK in Firefox et.al. with
> the default settings (i.e., no CRL checking), and users wanting to do
> revocation checking can manua
Nelson B Bolyard wrote:
Frank Hecker wrote, On 2009-02-23 11:30:
I have no problem with NSS ignoring CRLs with CIDP extensions in the
context of CRLDP support; however I think that (e.g.) Firefox should not
treat this as an error but should proceed as if no CRL were ever seen.
(I think it's OK t
Frank Hecker wrote, On 2009-02-23 11:30:
> I have no problem with NSS ignoring CRLs with CIDP extensions in the
> context of CRLDP support; however I think that (e.g.) Firefox should not
> treat this as an error but should proceed as if no CRL were ever seen.
> (I think it's OK to show an error mes
ma...@e-mice.net wrote re ignoring CRLs with the IDP extension:
This approach makes a lot of sense to the implementation because if
the implementation could know whether the certificate is on the list,
it has already supported CIDP and the question itself is not a
question any more. Right?
I'm
On Feb 21, 8:53 am, Frank Hecker wrote:
> 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 P
On Feb 21, 8:53 am, Frank Hecker wrote:
> 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 P
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
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
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
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
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 you for clarifying this. I'd like to get a final clarificat
Frank Hecker wrote:
[...]
* For non-EV certs I'd be willing to live with Nelson's option #3 in the
near term, if we can get the technical issues clarified (e.g., the
question Jean-Marc Desperrier had)[...]
It's now clarified, I had just made a stupid error when browsing through
the various ext
Jean-Marc Desperrier wrote:
[...]
Otherwise I'm surprised at the way they use the CRL DP/CRL IDP
extensions[...]
OK, so when writing that, I was making a stupid error confusing the
content of two extensions in the cert.
The content of the IssuingDistributionPoint is in fact perfectly
correc
Paul Hoffman wrote:
At 7:58 PM -0800 2/12/09, Nelson B Bolyard wrote:
Recently, a CA that uses partitioned CRLs applied to admission to
the Mozilla/NSS root CA list. Our choices appear to be:
1) Do not admit their root until support for partitioned CRLs is done.
(There is no active plan of rec
On 02/09/2009 08:44 PM, kathleen95...@yahoo.com:
This begins the one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved for inclusion.
If there are outstanding issues or action i
At 7:58 PM -0800 2/12/09, Nelson B Bolyard wrote:
>Recently, a CA that uses partitioned CRLs applied to admission to
>the Mozilla/NSS root CA list. Our choices appear to be:
>
>1) Do not admit their root until support for partitioned CRLs is done.
>(There is no active plan of record to do that wor
On Feb 13, 11:58 am, Nelson B Bolyard wrote:
> Michael Ströder wrote, On 2009-02-10 00:27:
>
> > Nelson B Bolyard wrote:
> >> This is probably a policy question, but: are we willing to accept CAs
> >> that use CRLs that we cannot parse?
>
> > I'd say no.
>
> >> Does this CA also implement OCSP? C
On 02/13/2009 05:58 AM, Nelson B Bolyard:
Recently, a CA that uses partitioned CRLs applied to admission to
the Mozilla/NSS root CA list. Our choices appear to be:
1) Do not admit their root until support for partitioned CRLs is done.
(There is no active plan of record to do that work at this t
Michael Ströder wrote, On 2009-02-10 00:27:
> Nelson B Bolyard wrote:
>> This is probably a policy question, but: are we willing to accept CAs
>> that use CRLs that we cannot parse?
>
> I'd say no.
>
>> Does this CA also implement OCSP? Can we justify this on the grounds
>> that we do implement
kathleen95...@yahoo.com wrote:
As reported inhttps://bugzilla.mozilla.org/show_bug.cgi?id=408949#c27
this CA uses partitioned CRLs with CRL IDP extensions marked critical.
NSS does not handle partitioned CRLs at this time, and any CRLs with
critical CRL IDP extensions are rejected due to the pres
Michael Ströder wrote:
Nelson B Bolyard wrote:
Does this CA also implement OCSP? Can we justify this on the grounds
that we do implement OCSP, and that OCSP will effectively displace CRLs
as the preferred revocation channel?
I'd say no. Use of OCSP should not be made mandantory.
I agree,
Nelson B Bolyard wrote:
> This is probably a policy question, but: are we willing to accept CAs
> that use CRLs that we cannot parse?
I'd say no.
> Does this CA also implement OCSP? Can we justify this on the grounds
> that we do implement OCSP, and that OCSP will effectively displace CRLs
> as
> As reported inhttps://bugzilla.mozilla.org/show_bug.cgi?id=408949#c27
> this CA uses partitioned CRLs with CRL IDP extensions marked critical.
> NSS does not handle partitioned CRLs at this time, and any CRLs with
> critical CRL IDP extensions are rejected due to the presence of
> unknown critica
Nelson,
Nelson B Bolyard wrote:
This is probably a policy question, but: are we willing to accept CAs
that use CRLs that we cannot parse?
It seems to me that the answer should be the same as for all other
subordinate CAs that exist today, over which the Mozilla foundation has
no control, and
Our esteemed kathleen95...@yahoo.com wrote on 2009-02-09 10:44 PST:
> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule
> Hongkong Post is the next request in the queue for public discussion.
>
> Hongkong Post (a national government CA under the law of Hong Kong
> Special Administrati
As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule
Hongkong Post is the next request in the queue for public discussion.
Hongkong Post (a national government CA under the law of Hong Kong
Special Administrative Region of China) has applied to add one new
root CA certificate to the Mozi
46 matches
Mail list logo
