[ca-tf] last version of the Certification Proposal

I wonder whether my previous letter was seen in the list.
If not, I can resend it, if yes, I would like to understand where I was 
wrong in my proposals, supporting Robert's comments.
I failed to see any changes in the proposal concerning the so called 
"secure channel".


Thanks in advance,
dol@


Filiz Yilmaz пишет:
> 
> 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
> 
> 
> 
> 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
>>