At 10:21 AM +1000 7/22/09, Geoff Huston wrote:
WG chair hat off
On 22/07/2009, at 8:32 AM, Stephen Kent wrote:
Geoff,
I was referring to the current CP document.
I think we should remove all references to algorithms from all
other documents, and refer to the CP.
I disagree with this approach. The reason for my disagreement is
that I was working under the impression that a "profile" document
takes a parent specification (or multiple specifications) and makes
a specific set of technical choices, where choice is allowed, with
the intention of defining a strict subset of the parent
specification that has the property that all implementations of the
profile will be able correctly interpret the products of other
conforming implementations. The intention of such a profile lies in
ensuring efficient interoperability, in that implementations that
conform to such a profile are not requirement to implement the
complete range of options encompassed in the parent specification.
This strikes me as a useful undertaking, particularly in the case
when the range of choices are potentially open ended.
I agree with your characterization of a profile, in general. However,
many profiles of X.509 do not specify algorithms, so that is not a
critical, or even common, feature of a cert profile. Because we are
creating spec for the RPKI, and because we are also creating the CP
for that PKI, we have an option to specify the algorithms there, as
an alternative.
It seems to me that if you are proposing that the CP take on that
role of profile definition through shift in the specification of
then the next logical step here would be to abandon the res-cert
draft completely and place the entire onus of definition of
conformance to a profile onto the CP document. I did not think that
CP documents carried the burden of actually defining a profile, and
from my understanding of the role of a CP document it seems to me
that it would be inadvisable to place the CP into such a role.
Well, section 4.7 of RFC 3647 (the CP template) is precisely a cert
and CRL profile section! So, based that template, we would be
justified in putting the whole cert/CRL profile in the CP. I think
we wisely decided to keep the CP shorter by having the cert/CRL
profile as a separate document. I also note that the cert profile
section (4.7.1) of 3647 lists algorithm IDs as part of what could be
present in the profile IF it were included. So, I think we have
leeway to put the algorithm discussion in either place. I believe it
might be preferable to keep the profile constant across algorithm
changes. If we believe that the CP will remain similarly static for a
long time, then we might be better off putting the algorithm specs in
another document, separate form both the CP and the cert/CRL profile.
As far as I can tell this is _a_ profile. It is not necessarily the
case that this will be the only such profile ever. Other profiles
may exist in the future, and such profiles may elect to use an
approach that is intended to be backward compatible with this
profile, or may deliberately elect to take a stance that is not
backward compatible with this profile. And it is conceivable that
the the CP OID value in conforming certificate products could well
be the distinguishing field that allows replying parties to identify
the associated intended profile and, accordingly, define their
actions in terms of interpretation of such objects. But, for me,
that does not imply that it is appropriate to allow the CP to
subsume the role of the vehicle for the technical specification of
the associated profile. So I do not believe that it is appropriate
to remove all reference to algorithms from all other documents, and
refer to the CP, and believe that the opposite is the case and that
the CP should refer to specifications that explicitly describe
algorithms as a integral part of the complete technical profile that
such specifications define.
The document you have written definitely is a profile. However, the
reference documents allow such a profile to include algorithm specs,
or not. I think we agree that the policy OID specified by the CP
should capture the alg spec as well as the cert/CRL profile. The
question is whether we put the alg spec in the profile, the CP, or a
third document.
If we agree that there will be a need to change the alg suite over
time, the we can discuss how we want to minimize the impact of such
changes.
if we agree that the goal for the RPKI is to mandate support for at
most two algorithm suites (current and next, to enable a transition),
then we should state that in the CP, even if we don't specify the alg
suites there.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
