Long-lived Certificates and CRLs
Jeremy Rowley
the decision to allow long-lived certificates with periodic revalidation.
The CRL size and speed issues only illustrate the need for a 39-month limit
on the lifetimes of SSL certificates. In fact, the current CRL problems are
only exacerbated by the new Mozilla policy of allowing long lived
certificates but requiring 3-year re-validation.
CRL size and speed problems will likely grow substantially with the recent
lifecycle change as a CA's only recourse for entities failing re-validation
is to add their certificates to the CRL. This results in large CRL
databases and slow response times, degrading everyone's browser experience.
A huge CRL file doesn't only hurt the CA, it also hurts the browser users
and the reputation of the browser.
In addition, existing software, in general, does not do any sort of
validation on key lifetimes. This leads to unlimited renewals, even through
revalidation reoccurs, and allows key holders to use keys for much longer
than they should. The Federal PKI policies only allow 2 renewals on the same
keys before a re-key must occur, effectively limiting the key lifetime to 9
years.
I really think every browser should limit SSL certificate lifespans to, at
most, 39 months with a maximum of two renewals and eliminate the concept of
re-validation plus revocation for long-lived SSL certificates. This change
will prevent a lot of CRL problems in the future.
Jeremy
Ryan Koski
<jeremy...@digicert.com> wrote:
> I really think every browser should limit SSL certificate lifespans to, at
> most, 39 months with a maximum of two renewals and eliminate the concept of
> re-validation plus revocation for long-lived SSL certificates. This change
> will prevent a lot of CRL problems in the future.
So scope your CRLs. RFC5280:
Each CRL has a particular scope. The CRL scope is the set of
certificates that could appear on a given CRL. For example, the
scope could be "all certificates issued by CA X", "all CA
certificates issued by CA X", "all certificates issued by CA X that
have been revoked for reasons of key compromise and CA compromise",
or a set of certificates based on arbitrary local information, such
as "all certificates issued to the NIST employees located in
Boulder".
You could define whatever scopes you want (e.g.- "SSL certificates
issued in April 2011"). You just need to make sure that whatever URI
you encode into a given certificate, that CRL file would contain the
revocation entry should that certificate ever be revoked. In the
prior example, you might have a URI like
'http://crl.digicert.com/ssl-201104.crl'. In such a case, the maximum
size of that CRL is constrained by the total number of certificates
issued during that month. You of course could use whatever criteria
you wanted to partition certificates into CRL scopes that made the
most sense for you. The trade off is that now you have to issue and
publish more CRL files, but each file can be small in size. Find the
balance that works best for you. It is probably also wise to publish
a complete CRL that contains all revoked certificates for the CA (for
linking from a repository page). However, that "master" CRL doesn't
need to be included in any CDP extension in any certificate.
In the past, some have mentioned the IDP extension complicating this
idea. I remember someone saying that in order to use scoped CRLs, you
have to have an IDP present, and IDP is defined as being critical,
which causes failures for certain relying applications. However, as I
read 5280, I cannot see anywhere where it says anything like "If you
have CRL scopes that are a subset of all certificate issued by a given
CA, then the CRL MUST contain the Issuing Distribution Point
extension." Nor could it contain such a rule, because the semantics
of the IDP extension provide no way to describe the "all certificates
issued to the NIST employees located in Boulder" example that is
explicitly given in the RFC.
I don't think CRL size is a valid reason to argue against longer-lived
certificates.
--
Ryan Koski
ryan...@gmail.com
Statements in this email are my own and are not necessarily those of
my employer.
Rob Stradling
<snip>
> In the past, some have mentioned the IDP extension complicating this
> idea. I remember someone saying that in order to use scoped CRLs, you
> have to have an IDP present, and IDP is defined as being critical,
> which causes failures for certain relying applications. However, as I
> read 5280, I cannot see anywhere where it says anything like "If you
> have CRL scopes that are a subset of all certificate issued by a given
> CA, then the CRL MUST contain the Issuing Distribution Point
> extension." Nor could it contain such a rule, because the semantics
> of the IDP extension provide no way to describe the "all certificates
> issued to the NIST employees located in Boulder" example that is
> explicitly given in the RFC.
Hi Ryan. We were discussing this yesterday in the "Revocation Checking via
Browser CRL/Cache Flushing" thread. I've reached the opposite conclusion.
RFC5280 Section 5.2.5 says:
The issuing distribution point is a critical CRL extension that identifies
the CRL distribution point and scope for a particular CRL.
My interpretation: When the IDP extension is not present in a CRL, the scope
is not explicitly "identified" within that CRL.
X.509 (08/2005) Section 8.5.1(e) says:
Certificate users need to be able to determine, from the CRL itself,
additional information including the scope of certificates covered by this
list...
My interpretation: The scope needs to be identified within the CRL, either
explicitly or implicitly.
X.509 (08/2005) Section 8.5.2.5 says:
If the CRL does not contain an issuingDistributionPoint,
AAissuingDistributionPoint, or crlScope extension, then the scope is the
entire scope of the authority, and the CRL may be used for any certificate
from that authority.
X.509 (08/2005) Section 8.6.2.2 makes the same point:
If the issuing distribution point field, the AA issuing distribution point
field, and the CRL scope field are all absent, the CRL shall contain
entries for all revoked unexpired public-key certificates issued by the CRL
issuer.
My interpretation: Where there is no scope explicitly identified within a CRL,
the scope is (implicitly) "all certificates issued by CA X". If you want a
different scope, you have to explicitly identify it. To do that, you have to
use the IDP extension (since the crlScope extension is deprecated and not even
mentioned by RFC5280, and the AAissuingDistributionPoint is not applicable to
public-key certs).
You said:
"However, as I read 5280, I cannot see anywhere..."
IMHO, 5280 doesn't explain CRL scoping in quite enough detail. X.509 does a
much better job.
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Ryan Koski
> IMHO, 5280 doesn't explain CRL scoping in quite enough detail. X.509 does a
> much better job.
Yes, but X.509 is an informative reference in RFC 5280, not normative.
http://www.ietf.org/iesg/statement/normative-informative.html :
"For example, an informative reference might provide background or
historical information. Informative references are not required to
implement the technology in the RFC."
I suppose this opens us up to the debate about which standard governs
in the case of explicit or perceived conflicts between X.509 and
RFC5280. It was my understanding that, for the purposes of operating
a CA that issues TLS certificates for use on the public Internet, that
the IETF/RFC5280 would govern. And as we both seem to agree, 5280
leaves more room for interpretation than X.509.
Again, if 5280 explicitly mentions a scope as "all certificates issued
to the NIST employees located in Boulder", it cannot possibly also
_require_ an IDP extension in such a CRL, as the syntax of the IDP
extension provides no way to describe that scope.
--
Ryan Koski
ryan...@gmail.com
Jean-Marc Desperrier
> as we both seem to agree, 5280
> leaves more room for interpretation than X.509.
No, the text in X.509 is just easier to comprehend. 5280 does not
actually leave more room for interpretation on this point.
> Again, if 5280 explicitly mentions a scope as "all certificates issued
> to the NIST employees located in Boulder", it cannot possibly also
> _require_ an IDP extension in such a CRL, as the syntax of the IDP
> extension provides no way to describe that scope.
But it does. It a very important property in RFC5280 that the
method/channel used to obtain the CRL *does* *not* matter, so therefore
the result of processing the CRL *can* *not* depend on it.
Or else it would be required to secure this channel, and non-ssl URL
would be forbidden.
It's the very opposite, the security considerations of RFC5280 warn
*against* using SSL to download CRL.
http://tools.ietf.org/html/rfc5280#section-8 :
CAs SHOULD NOT include URIs that specify https, ldaps, or similar
schemes in extensions. CAs that include an https URI in one of these
extensions MUST ensure that the server's certificate can be validated
without using the information that is pointed to by the URI
Steve Roylance
Does anyone know if Swiss Sign are on this mailing list? They seem to
use the SKI as the CRL CDP. I guess it works ;-)
Check out the cert on https://swisssign.com/en
Steve
On 27/04/2011 14:09, "Ryan Koski" <ryan...@gmail.com> wrote:
>On Wed, Apr 27, 2011 at 1:05 AM, Rob Stradling <rob.st...@comodo.com>
>wrote:
>
>> IMHO, 5280 doesn't explain CRL scoping in quite enough detail. X.509
>>does a
>> much better job.
>
>Yes, but X.509 is an informative reference in RFC 5280, not normative.
>
>http://www.ietf.org/iesg/statement/normative-informative.html :
>
>"For example, an informative reference might provide background or
>historical information. Informative references are not required to
>implement the technology in the RFC."
>
>I suppose this opens us up to the debate about which standard governs
>in the case of explicit or perceived conflicts between X.509 and
>RFC5280. It was my understanding that, for the purposes of operating
>a CA that issues TLS certificates for use on the public Internet, that
>the IETF/RFC5280 would govern. And as we both seem to agree, 5280
>leaves more room for interpretation than X.509.
>
>Again, if 5280 explicitly mentions a scope as "all certificates issued
>to the NIST employees located in Boulder", it cannot possibly also
>_require_ an IDP extension in such a CRL, as the syntax of the IDP
>extension provides no way to describe that scope.
>
>--
>Ryan Koski
>ryan...@gmail.com
>_______________________________________________
>dev-security-policy mailing list
>dev-secur...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
> On Wed, Apr 27, 2011 at 1:05 AM, Rob Stradling <rob.st...@comodo.com>
wrote:
> > IMHO, 5280 doesn't explain CRL scoping in quite enough detail. X.509
> > does a much better job.
>
> Yes, but X.509 is an informative reference in RFC 5280, not normative.
>
> http://www.ietf.org/iesg/statement/normative-informative.html :
>
> "For example, an informative reference might provide background or
> historical information. Informative references are not required to
> implement the technology in the RFC."
>
> I suppose this opens us up to the debate about which standard governs
> in the case of explicit or perceived conflicts between X.509 and
> RFC5280. It was my understanding that, for the purposes of operating
> a CA that issues TLS certificates for use on the public Internet, that
> the IETF/RFC5280 would govern. And as we both seem to agree, 5280
> leaves more room for interpretation than X.509.
>
> Again, if 5280 explicitly mentions a scope as "all certificates issued
> to the NIST employees located in Boulder", it cannot possibly also
> _require_ an IDP extension in such a CRL, as the syntax of the IDP
> extension provides no way to describe that scope.
The syntax of the IDP extension does not differ between X.509 and RFC5280, and
X.509 does document how to implement arbitrary CRL scopes using the IDP
extension.
I see your point about informative vs normative. It seems very odd that X.509
is only an informative reference, given that RFC5280 "profiles the X.509 v3
certificate and X.509 v2 certificate revocation list (CRL) for use in the
Internet" and that one purpose of RFC5280's profile is to
"promote...interoperability".
I'd be very surprised if the authors of RFC5280 (and its predecessors)
intended to introduce any conflicts with X.509.
I think it's time to take this issue to the PKIX mailing list.
Rob Stradling
> Hi Ryan,
>
> Does anyone know if Swiss Sign are on this mailing list? They seem to
> use the SKI as the CRL CDP.
No, they're using the AKI.
The cert at https://testevg2.swisssign.net was issued by the same EV Issuing
CA and contains exactly the same CDP URI.
So they're presumably using the "all certificates issued by CA X" CRL scope.
> I guess it works ;-)
>
> Check out the cert on https://swisssign.com/en
>
> Steve
>
> On 27/04/2011 14:09, "Ryan Koski" <ryan...@gmail.com> wrote:
> >On Wed, Apr 27, 2011 at 1:05 AM, Rob Stradling <rob.st...@comodo.com>
> >
> >wrote:
> >> IMHO, 5280 doesn't explain CRL scoping in quite enough detail. X.509
> >>
> >>does a
> >>
> >> much better job.
> >
> >Yes, but X.509 is an informative reference in RFC 5280, not normative.
> >
> >http://www.ietf.org/iesg/statement/normative-informative.html :
> >
> >"For example, an informative reference might provide background or
> >historical information. Informative references are not required to
> >implement the technology in the RFC."
> >
> >I suppose this opens us up to the debate about which standard governs
> >in the case of explicit or perceived conflicts between X.509 and
> >RFC5280. It was my understanding that, for the purposes of operating
> >a CA that issues TLS certificates for use on the public Internet, that
> >the IETF/RFC5280 would govern. And as we both seem to agree, 5280
> >leaves more room for interpretation than X.509.
> >
> >Again, if 5280 explicitly mentions a scope as "all certificates issued
> >to the NIST employees located in Boulder", it cannot possibly also
> >_require_ an IDP extension in such a CRL, as the syntax of the IDP
> >extension provides no way to describe that scope.
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Jeremy Rowley
problem's root. Not all CAs will adopt CA partitioning, and no one has
presented a requirement forcing them to do so. Those that don't use
partitioning will still cause a serious degradation in user experience.
User's aren't going to blame the CA for a slow internet. They will blame
the browser, especially if Mozilla is essentially encouraging CAs to issue
certificates for unlimited lengths of time and use revocation as the normal
mechanism for ensuring updated validation information. This is why the
validation cycle should correlate directly to the certificate lifecycle.
Jeremy
IMHO, 5280 doesn't explain CRL scoping in quite enough detail. X.509 does a
much better job.
Rob Stradling
Rob Stradling
> Although partitioning could reduce CRL problems, the solution ignores the
> problem's root. Not all CAs will adopt CA partitioning, and no one has
> presented a requirement forcing them to do so. Those that don't use
> partitioning will still cause a serious degradation in user experience.
> User's aren't going to blame the CA for a slow internet. They will blame
> the browser, especially if Mozilla is essentially encouraging CAs to issue
> certificates for unlimited lengths of time and use revocation as the normal
> mechanism for ensuring updated validation information. This is why the
> validation cycle should correlate directly to the certificate lifecycle.
Requiring the validation cycle to correlate directly to the certificate
lifecycle just because *some* CAs won't adopt CRL partitioning doesn't seem
quite fair to me.
What about CAs who are prepared to adopt CRL partitioning? Why shouldn't they
be allowed to issue certificates that are valid for longer than the
"validation cycle" ?
<snip>
Erwann Abalea
-----
...
The syntax and semantics for the distributionPoint field are the same
as for the distributionPoint field in the cRLDistributionPoints
extension (Section 4.2.1.13). If the distributionPoint field is
present, then it MUST include at least one of names from the
corresponding distributionPoint field of the cRLDistributionPoints
extension of every certificate that is within the scope of this CRL.
The identical encoding MUST be used in the distributionPoint fields
of the certificate and the CRL.
...
-----
That's a way to limit the scope of a CRL to "all certificates issued
to the NIST employees located in Boulder", but it requires:
- that all these certificates have a CRLDP URI in common
- that thet CRL retrieved by this URI contains a critical issuingDistributionPoint extension containing this URI in the DistributionPoint field
This paragraph is getting more and more confusing with time. X.509, in its 1997 edition, the issuingDistributionPoint definition contains this text:
-----
The distributionPoint component contains the name of the distribution point in one or more name forms. If this field is absent, the CRL shall contain entries for all revoked unexpired certificates issued by the CRL issuer.
-----
That's way simpler and clearer, as it tells that the presence of this extension limits the scope of a CRL, and the fields define the possible scopes. Among them, the distribution URI.
BTW, I know at least one CA that publishes CRLs accessible only by a client-authenticated TLS link. Bad, very bad, but it exists.
It's the SWIFT's CA. I'm still waiting to be able to verify this implementation, as certificates seem to have different CRLDP URIs. If the retrieved CRL doesn't have a critical IDP extension, they fail. As this PKI is used in the banking business, failure to implement standards is not acceptable.
Erwann Abalea
Erwann Abalea
RFC5280 is to be seen as a "layer" on top of X.509, limiting possible choices. But RFC5280 cannot allow something forbidden by X.509.
Erwann Abalea
Jean-Marc Desperrier
> The URI used to get the CRL can matter.
Is that a response to my message Erwann ? (Your message is missing the
reference header then).
The URI *value* that's present in the certificat can matter, but not the
URI used to *get* the CRL.
And you're quoting the one case where the value matters, when testing if
a CRL with the *critical* IDP extension can be used to validate a
certificate.
But the presence of the IDP extension inside the CRL will not vary
whatever the channel you used to obtain it, so the channel itself does
not matter.
> BTW, I know at least one CA that publishes CRLs accessible only by a
> client-authenticated TLS link. Bad, very bad, but it exists.
I said "RFC5280 warn *against*". It's not forbidden as long as it's
possible to validate the server's certificate without using the
information that is pointed to by the CRLDP URI.
> It's the SWIFT's CA. I'm still waiting to be able to verify this
> implementation, as certificates seem to have different CRLDP URIs. If
> the retrieved CRL doesn't have a critical IDP extension, they fail.
> As this PKI is used in the banking business, failure to implement
> standards is not acceptable.
In fact, they (but you could say rather their PKI provider Entrust) use
IDP to partition CRL, but IDP used in this is a standard, not just
RFC5280, as Rob said already.
Quoting X.509 (08/2005) :
8.6.2.2 Issuing distribution point extension
[...]
If the CRL contains an issuingDistributionPoint extension with the
distributionPoint field present, at least one name for the distribution
point in the certificate (e.g., cRLDistributionPoints, freshestCRL,
issuer) shall match a name for the distribution point in the CRL.
[...]
This extension is always critical. A certificate user that does not
understand this extension cannot assume that the CRL contains a complete
list of revoked certificates of the identified authority
Jeremy Rowley
CRL issues are just one more example of the many problems associated with
long-lived certificates. For end-users, certificate expiration and
reissuance is a better model than long-lived certificates.
Jeremy
-----Original Message-----
From: Rob Stradling [mailto:rob.st...@comodo.com]
Sent: Thursday, April 28, 2011 1:56 AM
To: dev-secur...@lists.mozilla.org
Cc: Jeremy Rowley; 'Ryan Koski'
Subject: Re: Long-lived Certificates and CRLs
Brian Smith
> Requiring the validation cycle to correlate directly to the
> certificate lifecycle just because *some* CAs won't adopt
> CRL partitioning doesn't seem quite fair to me.
>
> What about CAs who are prepared to adopt CRL partitioning? Why
> shouldn't they be allowed to issue certificates that are valid
> for longer than the "validation cycle" ?
Off the top of my head:
1. When a new cert is required for each validation, there is observable evidence of the validation, and less need to rely on attestations from CAs that they have complied with our requirements. We need to move away from reliance on attestations, contracts, and auditing and towards enforcing policy in software based on observable (by the browser) evidence, whenever it is possible to do so. (This is the same reason we must move away from allowing sub-CAs.)
2. Changes to our policy that affect security are hampered by long-lived certificates. Although certificate lifetime shouldn't affect our decision making, it makes the decision to deploy security enhancements easier, when we know that the lifetime of certs with poor characteristics is limited. For example, the main reason we can't disable MD5-based certificates *today* because of certificates that were issued off Equifax roots in 2008.
3. Certificate renewal gives customers and CAs an opportunity to make improvements (e.g. adding additional information, removing disclaimers, moving to a different intermediate) that enhance the ability of the browser to provide useful information to users.
4. The more CRLs are partitioned, the easier it is to infer which website motivated the loading of each CRL. This is a privacy issue, if we load CRLs from CAs.
5. If we implement something like the "browser CRL" we are discussing in another thread, the quantity of CRLs that cover all certificates becomes a limiting factor.
- Brian
Ben Wilson
I think you meant to say,
- Brian
Rob Stradling
> It's not about what is and isn't fair.
Hmmm...I understood "Not all CAs will adopt CA partitioning...This is why the
validation cycle should correlate directly to the certificate lifecycle" to be
saying that adopters should be limited because non-adopters also exist.
Rob Stradling
> Jeremy Rowley wrote:
> > Requiring the validation cycle to correlate directly to the
> > certificate lifecycle just because *some* CAs won't adopt
> > CRL partitioning doesn't seem quite fair to me.
> >
> > What about CAs who are prepared to adopt CRL partitioning? Why
> > shouldn't they be allowed to issue certificates that are valid
> > for longer than the "validation cycle" ?
>
> Off the top of my head:
>
> 1. When a new cert is required for each validation, there is observable
> evidence of the validation, and less need to rely on attestations from CAs
> that they have complied with our requirements. We need to move away from
> reliance on attestations, contracts, and auditing and towards enforcing
> policy in software based on observable (by the browser) evidence, whenever
> it is possible to do so.
I tend to agree, but then I'm just a techie. I expect others will want to
fiercely defend "reliance on attestations, contracts and auditing".
> (This is the same reason we must move away from
> allowing sub-CAs.)
>
> 2. Changes to our policy that affect security are hampered by long-lived
> certificates. Although certificate lifetime shouldn't affect our decision
> making, it makes the decision to deploy security enhancements easier, when
> we know that the lifetime of certs with poor characteristics is limited.
> For example, the main reason we can't disable MD5-based certificates
> *today* because of certificates that were issued off Equifax roots in
> 2008.
Fair point.
> 3. Certificate renewal gives customers and CAs an opportunity to make
> improvements (e.g. adding additional information, removing disclaimers,
> moving to a different intermediate) that enhance the ability of the
> browser to provide useful information to users.
Another fair point.
> 4. The more CRLs are partitioned, the easier it is to infer which website
> motivated the loading of each CRL. This is a privacy issue, if we load
> CRLs from CAs.
I don't think anyone's advocating that CRL partitioning should be banned
though (or are you suggesting that?) And anyway, the same privacy issue
already exists for non-stapled OCSP, and modern browsers tend to prefer to use
OCSP (when available) instead of CRLs.
(I wonder...could some text be added to the Mozilla CA Certificate Policy that
would prevent, albeit in a non-technically-enforce fashion, CAs from using
their OCSP/CRL server logs for anything "bad" in terms of user privacy?)
> 5. If we implement something like the "browser CRL" we are discussing in
> another thread, the quantity of CRLs that cover all certificates becomes a
> limiting factor.
True.
Ian G
> On Friday 29 Apr 2011 02:28:42 Brian Smith wrote:
>> 1. When a new cert is required for each validation, there is observable
>> evidence of the validation, and less need to rely on attestations from CAs
>> that they have complied with our requirements. We need to move away from
>> reliance on attestations, contracts, and auditing and towards enforcing
>> policy in software based on observable (by the browser) evidence, whenever
>> it is possible to do so.
>
> I tend to agree, but then I'm just a techie. I expect others will want to
> fiercely defend "reliance on attestations, contracts and auditing".
Yep. I used to be a techie, and then I discovered attestations,
contracts and auditing :)
Tech is like minefields. It only works while heavily-armed soldiers are
watching and patrolling them.
iang
Rob Stradling
> On Wednesday 27 Apr 2011 14:09:43 Ryan Koski wrote:
> > > does a much better job.
> >
> >
> > http://www.ietf.org/iesg/statement/normative-informative.html :
> >
> > "For example, an informative reference might provide background or
> > historical information. Informative references are not required to
> > implement the technology in the RFC."
> >
> > I suppose this opens us up to the debate about which standard governs
> > in the case of explicit or perceived conflicts between X.509 and
> > RFC5280. It was my understanding that, for the purposes of operating
> > a CA that issues TLS certificates for use on the public Internet, that
> > the IETF/RFC5280 would govern. And as we both seem to agree, 5280
> > leaves more room for interpretation than X.509.
> >
> > Again, if 5280 explicitly mentions a scope as "all certificates issued
> > to the NIST employees located in Boulder", it cannot possibly also
> > _require_ an IDP extension in such a CRL, as the syntax of the IDP
> > extension provides no way to describe that scope.
>
> and X.509 does document how to implement arbitrary CRL scopes using the
> IDP extension.
>
> I see your point about informative vs normative. It seems very odd that
> X.509 is only an informative reference, given that RFC5280 "profiles the
> X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for
> use in the Internet" and that one purpose of RFC5280's profile is to
> "promote...interoperability".
>
> I'd be very surprised if the authors of RFC5280 (and its predecessors)
> intended to introduce any conflicts with X.509.
>
> I think it's time to take this issue to the PKIX mailing list.
Ryan, FYI, somebody else has asked on the PKIX list:
http://www.ietf.org/mail-archive/web/pkix/current/msg29216.html
I've just replied to that thread with a summary of your argument and suggested
that a defect report might be required.