...
At Wed, 9 Jun 2010 15:38:24 -0400, Steve Kent wrote:
...
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.
Where in that paragraph (or anywhere in Sam's document) does it say
that the TA certificate doesn't contain 3779 extensions? At least one
of us is confused on this point.
Sam's text in the last paragraph of section 4 said "... delegating
all of the resources in the certificate to a single child ..." I
misread this text to mean that the TA could have its 3779 extensions
moved to the CA cert under it. A less ambiguous description of what I
think Sam meant is the wording that I used in my description.
...
Other than the inherit bit, this is what I think the draft already
says, or at least is trying to say. More on the inherit bit below.
in retrospect I agree.
...
Using the inherit bit here is clever. I'm not sure I believe that it
needs to be mandatory, that seems like a choice the operator should be
allowed to make. It's straight RFC 3779 in either case, no magic, so
relying parties have to cope with either option in any case.
...
I'd have no problem with a SHOULD regarding use of the inherit bit,
just don't see the need for a MUST.
agreed.
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.
The current proposal says that the certificate conforms to the
profile, which in turn mandates the CRL. No harm in saying so
explicitly if you're more comfortable with that, but it's already part
of the specification by reference as far as I can tell.
yes, I think this needs to be stated explicitly. TAs are special,
are self-signed certs. See 5280 for the various cases where they are
called out as exceptions. So, for example there is not CRL issued for
the TA here, because it is self-signed. But, in all other respects
it is a resource cert :-).
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
