So much for mandatory support of v3 certs in RFC1422. You can use them if
you want to, but it is possible to have an entirely conforming
implementation
without them. This will not change until a standards-track document comes
along and says otherwise.
Since RFC 1422 specifically says that the version is version 1, I'm not even
sure that this is true. The appropriate thing to do is to revise or replace
1422.
Good point I hadn't thought of. I haven't reviewed the prose yet, but if what
you say is true this definitely needs to be examined carefully. It could be
that RFC 1422 is inconsistent on allowing support of new versions.
However, There is scope for further work to 1422, whereby the 1422
procedures might make use of the std extensions. 1422 is "poor"
currently, in that it suggests use of the issuerUniqueIdentifier as a
qualifier for identitying the parent-CA key to be used to validate a CA
certificate. A defect to 1422 needs to be issued to change or facilitate
better
handling of 1992 certificates to utilise the new standard extensions
which specifically have the function of solving the issue of a single CA
certificate being signed by multiple PCAs. The exploitation of a specific
syntactic and semantic contruct whose function it is to allow
originator selection between the available authentication channels
does extend 1422 certificate chain handling. I see this as a fallout of the
defect process, rather than a flaw of 1422.
There is certainly work that could be done along these lines, in particular to
remove the rather onerous requirement for name subordination and replacement
with an exp[licit indication of the PCA-CA-user chain.
I too would welcome some clarification here.
The question of a single CA certificate being signed by multiple PCAs, or a
single user being signed by multiple CAs, I find more problematic. This will
take a lot more discussion.
HUGE can of worms, I think.
If we were only going to upgrade the version number to permit v3, perhaps
clarify the optional or nonoptional status of nextUpdateDate, and discuss the
implementation of the critical flag, a standards track amendment would be the
way to go.
But my sense is that it is time for some more extensive revisions, including
updating the certificate chain to stop at one or more trusted root keys,
instead of the PCA or IPRA necessarily, the PCA-CA-user hierarchy, and
probably
a number of other extensions.
Hmm. Well, while I think such changes would be good, in the abstract at least,
I also think that this could easily add lots of delay. The question becomes one
of which is more important, a timely specification or a complete revisiting
of all the issues.
I would tend towards the latter, but that's just a personal preference which I
cannot back up with any compelling technical argument.
I would actively support such an revision effort, and suggest that we do
whatever is necessary to charter a work group to address this issue.
Excellent idea! Chartering a new working group to deal ***SPECIFICALLY*** with
changes to the certificate structure and model is a wonderful idea.
One final comment. I would recommend that the focus be specifically on X.509
cert, definitely in but not exclusively in the context of RFC1422. While there
is considerable appeal to broadening the effort to look at using other
certificate systems, working on interoperability between the systems, and so
on, it seems to be that this is the sort of siren song masking very deep
matters that could easily lead to getting nothing done.
Ned