Re: [ca-tf] last version of the Certification Proposal

[Filiz Yilmaz filiz@localhost]

Dear Basil,

I have seen your mail. I understand that you do not find LIR Portal  
secure however, the proposal does not state it is secure. It rather  
says a secure channel will be used and at the time  the proposal was  
written this medium is considered to be LIR Portal by the CA TF  
members (as there is no other medium known currently).
Regarding the exact wording, like I mentioned before, more comments  
will be received from the community once the proposal is published.  
At this point, the understanding was to have the proposal published  
asap so that community will have the chance to review it at least a  
week before Dubai meeting.
Kind regards,
Filiz

On 16 Oct 2008, at 12:44, Basil Dolmatov wrote:

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