...
Firstly, I'd like to point out that the approach described in this
draft, namely that of public key plus URL and a self signed RPKI
certificate) is the approach described in
draft-ietf-sidr-res-certs-06.txt through to
draft-ietf-sidr-res-certs-11.txt. The terminology was altered
slightly across that sequence of drafts in response to inputs from
Steve Kent, but the concept of using a very simple approach of using
the public key plus URL was what was originally envisaged for the
RPKI back in 2007-2008 when those versions of the draft were
submitted to the drafts repository.
The changes made in version 12 of that draft were made in response
to messages from Steve Kent and Russ Housley, which pointed out what
they believed to be specific weaknesses in this key plus URL
approach to the TA that implied that in their opinion this was not a
viable approach to the TA. If they are still of the opinion that
this approach is not viable then I guess that they should say so
once more and present their arguments in support of that view, this
time to the WG.
Geoff
Geoff,
I read the Sam's TA draft and sent comment directly to him yesterday.
But, since you requested feedback from Russ and from me on the list,
I'll recap my comments here.
The new TA proposal has a few problems.
From a terminology perspective it has a problem of the sort that Russ
and I noted 2 years ago in the proposal you cited. Specifically, the
self-signed cert is really the TA, as per RFC 5280 and RFC 5914. The
public key and URI are external mechanisms used to acquire and verify
the TA. They are not the TA. Such mechanisms are outside the scope
of PKIX and X.509 standards, so the proposal here is not violating
any of those standards. It just defines the wrong data as being a TA.
There also is a technical error in the paragraph at the end of
Section 4, where the new I-D describes how one could operate the CA
for the self-signed cert in an offline fashion. The text calls for
the TA to not contain a 3779 extension. That is not compliant with
3779. RFC 3779 requires that the TA at which a path terminates
contain a 3779 extension that encompasses all subordinate certs.
However, if one put the 3779 extensions in the TA (self-signed cert),
and set the inherit bit in the (immediate) subordinate CA cert, one
could achieve the desired offline operation goal that the I-D
describes. This would then comply with RFC 3779.
So, the I-D could be rewritten to fix the terminology problem and the
technical problem cited above.
I think the notion of an offline TA and an online CA below it are
important from a secruity perspective. Both the compound TA model and
this proposal can achieve that functionality if the new proposal is
modified as noted above, and if the use of the subordinate CA (with
the inherit bit) is mandated, not an option.
I also think it important to have an explicit, mandatory mechanism
for revocation of an online CA (TA). This is motivated by the
observation that the primary motivation for having matching online
and an offline cert issuers is because one believes that online
instance is more vulnerable than the offline one. Well, if that
belief is true, one needs to be prepared to revoke the online CA's
cert, using the offline CA. The compound TA mechanism does that by
having the ETA revoke the EE cert that is used to validate the CMS
blob that holds the RTA. I don't recall the current proposal making
a mention of a comparable function. That can be fixed by having the
new proposal say that the TA will maintain a CRL and that it will
revoke its subordinate CA, if needed.
If all of these changes were made to the new proposal, both
approaches would seem equivalent in functionality and security. The
new proposal would be somewhat simpler, as it would not make use of
the CMS structure that is employed in the compound TA model. However,
code already exists for the compound TA model, processing of signed
CMS objects is pretty well understood (based on S/MIME
implementations), and the differences are relatively minor, in my
opinion. Also, once we correct the terminology and label the
self-signed cert with the 3779 extensions as a TA, we have the
slightly odd situation that the TA is not static, i.e., that cert
will change with every new resource allocation. That does not
conflict with any PKIX RFC, to the best of my knowledge, but it may
confuse some folks who are accustomed to the notion of a TA being a
self-signed cert that does not change for a long time.
Does this analysis satisfy your request?
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
