[ca-tf] last version of the Certification Proposal

Nigel, thanks for your comments.

  > Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote:
  > > please find below a modified draft according to what I really would like to see.
  > > I guess the language of my small changes makes my point better then
  > > previous long messages.  ("small changes" = few words, the semantic change
  > > is bigger:-)
  > > (Of course lots of additional words could be used about the tradeoffs...)
  > >
  > > I certainly think that starting the policy process is more important now han
  > > the exact language of the proposal;  some discussion should be expected 
  > > anyway.
  > >   
  > If I can summarise your changes as I see them:
  > 
  > 1. You want to clarify that if a PA allocation is returned for some 
  > reason, then the associated certificate is revoked but that the manner 
  > of doing this is outside of scope


  > 2. You wish to clarify that certificates won't be arbitrarily revoked
+ I'm happy that process and burden on NCC actually can be simplified
while improving predictability for all the good players - 
extending a free ride by a few months for the minority of bad players
does not seem a serious drawback.

  > 3. You make a point about certificates being reissued after a dispute to 
  > represent the resolution of the dispute.
it's not about handling a "dispute".
It's about handling a security compromise after which certificates
depending on a compromised key will be revoked.
(When writing I essentially had in mind dealing with disaster hitting the NCC
- looking at it now I'm actually happy that the language seems to be very
very supportive to the address holder, and I think that's good!)
Even if disaster is unlikely it certainly is a good thing to have the
basic rules for dealing with it well defined and known
("In the unlikely event of loss of cabin pressure...")

  > I think that 1. could be usefully addressed, although it may seem a bit 
  > self evident.
Yes, it looks somewhat self evident. It helps to explicitly state
all relevant certificate transistions (initial creation, renewal, expiration,
revocation) with their conditions - which seems to be a good thing if
the complete text stays short and simple.

  > 3. is a valid point, but I think it is important not to go 
  > too deeply into the operational details in this proposal. Likewise I 
  > feel that 2. is adequately covered by the policy as currently stated.
  >
  > Thoughts anyone?
  > 
  > Nigel

Regards,
  Ruediger


Ruediger Volk

Deutsche Telekom AG -- Internet Backbone Engineering

E-Mail:  rv at NIC.DTAG.DE