[ca-tf] last version of the Certification Proposal

Hello,

After these comments, Nigel kindly edited the proposal text for a new  
version as attached.
I think the wording is not very brief but as mentioned by others too,  
it is more important to get this out for community review asap now.
Hopefully it can be improved after community's review over it. I will  
publish the attached version before the end of the day.

Thanks everyone for their input.

Regards,
Filiz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposal_in_template_draft06.doc
Type: application/octet-stream
Size: 30208 bytes
Desc: not available
Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20081016/9845db79/attachment.obj 
-------------- next part --------------



On 10 Oct 2008, at 14:49, Ruediger Volk, Deutsche Telekom T-Com -  
TE141-P1 wrote:

> 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
>