Geoff,
Thanks for your comments. response inline.
...
I assume that you are defining the distinction between a "non-leaf"
CA and a "leaf" CA as being one where a "leaf" CA only has EE
subordinates. It this a correct assumption. Your final comment about
this date applying to IANA and the RIRs does not quite capture for
me the same goal as the body of this paragraph.
Yes, leaf CAs are ones that issue only EE certs.
My parenthetical comment was meant to note that this first date might
apply only to top tier CAs, IF we choose to adopt a top-down
deployment approach. The rest of the text does not make such an
assumption, so maybe it was a mistake to make this comment here, sine
I failed to carry it through i the rest of the discussion. Let's
table the top-down discussion for now.
I also gather the impression that you see Proof of Possession
validation requiring the CA to have the ability to process the
algorithm used by the subordinate when the subordinate entity
generated the key pair. The RPKI provisioning protocol does not
specify any such direct test using the subordinate's public key
value. I am wondering if there is a missing element in the
provisioning protocol, namely the inclusion of such a direct test
of PoP, and what they would imply in any case. Is the nature of the
PoP test one of the issuer assurring itself that the requestor
really is the party they are purporting to be, or whether the PoP
test is one of the issuer assuring itself that the requestor really
has possession of the associated private key?
The CP mandates that every CA engage in PoP as part of cert issuance.
if the provisioning protocol does not make use of PoP, there is a
mismatch. I have not looked at the protocol, so I can't say any more
on that topic.
If the former is the case, then the issuer does not necessarily need
to have the ability to process the algorithm identified in the
certificate request. If the latter than the rescert provisioning
protocol may well be missing a needed step in verification of the
request.
Agreed.
> - CA Set <next alg suite name>: By his date all CAs MUST be
prepared to issue a certificate signed under the new algorithm suite
to a child CA that requests such. At this stage there is no
requirement that any CA issue such certificates, but rather that all
(not leaf) CAs be prepared to do so upon request.
>
How does a requestor specify the algorithm to be used by the issuer?
Again my concerns here is that there is something missing in section
6 of the res-cert draft if it is indeed necessary that the requestor
specify the algorithm that the issuer must use in generating the
certificate the describes the subject.
Good question. The parent CA might establish a separate "portal" via
which requests are made to the new vs. current alg suite. I have not
looked at the cert request formats to see if there is a provision to
indicate the alg suite to be used, but your comment suggests that
there is not. So, I think it might be easier to say that each CA must
advertise (via its CPS) how subjects can indicate the alg suite under
which a request is to be fulfilled.
...
Now here I'm somewhat confused. Are you talking about a parallel,
but entirely distinct certificate hierarchy? i.e. are you in effect
saying that the condition here is that all certificates issued for a
subject using subject key algorithm X are issued by the issuer with
a certificate signature algorithm also of algorithm X?
essentially, yes. Parallel CA certs, CRLs, manifests, and ROAs. As
noted, if we adopt the suggestion you made about revising the
manifest and ROA formats to accommodate dual sigs, we could have just
one set of these objects, but the CAs certs and CRLs are distinct.
...
I want to conform something here - are the CAs for the new and old
suite distinct? Whats the scope of the CRLs? I assume that it would
be an undesireable situation if a CRL from the "new" suite attempts
to revoke a certificate from the "old" suite, and I'm unsure what
mechanism would be used to prevent such a scenario from occurring.
The CAs represent the same administrative entity, which may or may
not have the same name, depending on the outcome of another
discussion. The CA instances use different keys to sign certs and
CRLs, so there is no ambiguity re CRL scope. Each CRL lists serial
number of certs issued under the corresponding CA key.
...
What you are in effect saying, as far as I can tell, is that the RP
is to switch over to believe the new "suite" if the results of the
"new" and "old" differ. I wonder how such a switch in collective RP
behaviour could be coordinated so precisely across all RPs. Or are
you saying that the onus is on all CAs to ensure that the two
environments are absolutely and precisely synchronized such that
there is no possibility for such a situation?
This is the date after which CAs are relieved of the burden of
issuing signed objects under the old suite. It is not a statement
about RP behavior, but we are past the RP Ready date, so RPs MUST be
able to process new alg suite signed objects, and not rely on any old
alg suite objects.
> - EOL <old alg suite name>: At this date NO signed objects
under the old algorithm suite are generated or consumed. More
formally, every CA and every RP MUST NOT generate certs, CRLs, or
other RPKI signed objects under the old alg suite. The transition is
now complete.
>
Note that during the interval when current and new algorithm
suites are in use (from CA Set <alg suite name> until Twilight <alg
suite name>) a CA MUST be prepared to process key rollover requests
for children under both current and new suites. There are a lot of
details to be worked out for this.
indeed!
I have a minor in understatement :-).
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
