Kyle Hamilton wrote:
So. If I understand correctly:
snip
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
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
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
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
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 obtain
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).
snip
FWIW, here's the definition from RFC 5280, which might
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
On Tue, Feb 24, 2009 at 4:53 PM, kathleen95...@yahoo.com 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,
On Feb 21, 8:53 am, Frank Hecker hec...@mozillafoundation.org 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
On Feb 21, 8:53 am, Frank Hecker hec...@mozillafoundation.org 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
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
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
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
On Mon, Feb 23, 2009 at 11:30 AM, Frank Hecker
hec...@mozillafoundation.org 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
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
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 Post
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)
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
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
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
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
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 you for
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,
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
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
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 current
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
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
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
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
On Feb 13, 11:58 am, Nelson B Bolyard nel...@bolyard.me 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?
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 work at
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
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 OCSP, and
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
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
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 the
Michael Ströder wrote:
Nelson B Bolyard wrote:
snip
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
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
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 Administrative
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,
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 critical
42 matches
Mail list logo
