Re: [Gen-art] Gen_ART review of draft-santesson-auth-context-extension-10

2015-11-22 Thread Stefan Santesson
Thank you, I have now seen this and I will address this in the final document update. /Stefan On 20/11/15 02:12, "Jari Arkko" wrote: >Thanks for your review, Jouni! > >(Authors, did you see this review - wanted to make sure no information is >lost.) > >Jari > >On 16 Oct 2015, at 01:56, jou

[Gen-art] RE: Gen-ART review of draft-santesson-tls-supp-00.txt

2006-04-11 Thread Stefan Santesson
standards building on top of this specification need to be formed. Stefan Santesson Program Manager, Standards Liaison Windows Security > -Original Message- > From: Tom-PT Taylor [mailto:[EMAIL PROTECTED] > Sent: den 11 april 2006 23:20 > To: Stefan Santesson > Cc: Russ

RE: [Gen-art] Gen-ART review of draft-santesson-tls-supp-00.txt

2006-04-12 Thread Stefan Santesson
The updated draft 01 has amended the IANA considerations section requesting this number to be assigned. Stefan Santesson Program Manager, Standards Liaison Windows Security > -Original Message- > From: Tom-PT Taylor [mailto:[EMAIL PROTECTED] > Sent: den 12 april 2006 15:18 >

[Gen-art] RE: Gen-ART review of draft-santesson-tls-ume-04.txt

2006-04-14 Thread Stefan Santesson
A few comments in line; Stefan Santesson Program Manager, Standards Liaison Windows Security > -Original Message- > From: Tom-PT Taylor [mailto:[EMAIL PROTECTED] > Sent: den 13 april 2006 20:25 > To: Russ Housley > Cc: Stefan Santesson; Ari Medvinsky; Joshua Ball; g

[Gen-art] Gen-art review of draft-ietf-avt-srtp-not-mandatory-05

2010-05-27 Thread Stefan Santesson
I am the assigned Gen-ART reviewer for draft-ietf-avt-srtp-not-mandatory-05.txt. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. This draft may be on th

Re: [Gen-art] Gen-ART review of draft-ietf-pkix-certimage-10

2010-08-23 Thread Stefan Santesson
Thank you, These seems like good suggestions. I will incorporate them. /Stefan On 10-08-23 8:45 PM, "Vijay K. Gurbani" wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >

Re: [Gen-art] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-25 Thread Stefan Santesson
Hi David, Thanks for the review. My reply in line. On 3/26/13 1:25 AM, "Black, David" wrote: >Authors, > >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please >see the FAQ at . > >Please resolve these comm

Re: [Gen-art] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-27 Thread Stefan Santesson
quirement. Why is that the case? > >-- > >Beyond that, the proposed actions (or proposed non-actions) on items >[2]-[5] >are fine with me, Sean's taken care of the author permissions item from >idnits, and I assume someone has or will check the ASN.1 . > &g

Re: [Gen-art] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-27 Thread Stefan Santesson
uot;running >code" >concerns, IMHO) and alternatives to using "revoked" ("have a number of >tools >to prevent the client from accepting a bad certificate") seem particularly >relevant. > >Thanks, >--David > >> -Original Message- >> Fro

Re: [Gen-art] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-28 Thread Stefan Santesson
eaching a (compromise) decision, it really is valuable >to record why the decision was reached to avoid recovering that ground >in the future and (specific to this situation) to give implementers some >more context/information on how the protocol is likely to work in >practice. > &g

Re: [Gen-art] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-28 Thread Stefan Santesson
>"revoked" is optional, and the existing text on CRLs as a fallback >mechanism suffices to illuminate a likely consequence of not using >"revoked". > >Thank you, >--David > >> -Original Message- >> From: Carlisle Adams [mailto:cad...@ee

Re: [Gen-art] [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-29 Thread Stefan Santesson
On 3/29/13 5:17 PM, "Piyush Jain" wrote: >' "revoked" status is still optional in this context in order to maintain >backwards compatibility with deployments of RFC 2560.' > >I fail to understand this statement about backward compatibility. >How does "revoked" being "optional/required breaks back

Re: [Gen-art] [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-29 Thread Stefan Santesson
On 3/29/13 6:12 PM, "Piyush Jain" wrote: >It is your statement about backward compatibility to justify it that is >incorrect. >Backward compatibility "with deployments of RFC2560" is not affected in >either case. Legacy clients will continue to work whether you make it >required or optional. Leg

Re: [Gen-art] [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-29 Thread Stefan Santesson
Legacy servers would not comply with RFC2560bis IF revoked response for non issued certs would be required. /Stefan On 3/29/13 10:06 PM, "Piyush Jain" wrote: >Not sure if I understand. >Are you saying legacy servers won't work with 2560bis clients? > >> On 3/29/13 6:12 PM, "Piyush Jain" wrote:

Re: [Gen-art] [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-04-09 Thread Stefan Santesson
On 4/9/13 2:35 PM, "Black, David" wrote: >Again speaking for myself, I think the current text in -16 is ok, in that >I >don't see the prohibition that Piyush is concerned about there. OTOH, >I'd also >be ok with a couple of sentences added to say that (new) clients could use >that response forma

Re: [Gen-art] [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-04-09 Thread Stefan Santesson
It is impossible to write a text that cannot deliberately be misunderstood. This debate is so full of constructed, non-existent problems. Nothing has changed for the clients. The client can receive an error, or they can receive (good, revoked or unknown). The meaning of those responses are pretty