Subject: Re: [pkix] FW: New Version Notification for draft-wallace-est-alt-challenge-00.txt

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Feb 2016 12:40:57 +0000

Well, it still is "after IETF94" I guess, but with apologies
to the authors for dropping this ball...

I've given this a read and have a question and a comment:

Question:

3.1: There are many OTP schemes in real use, and some CA might
someday support >1 - why don't you need a mechanism-id or
similar? (And section 5 here even calls out two different
schemes that are documented in RFCs.) If you tell me that you
think this isn't really needed (and if nobody else argues
for it, that'll be fine but I wanted to ask.)

Comment:

intro: Editorial suggestion: maybe list the existing uses of
the field in a numbered list and refer back to that when
necessary. I think that might help the reader to keep the
different uses clear as they read.

Once the authors have responded to the question above, I'll
start IETF LC for this one.

Cheers,
S.

PS: This was one of the drafts that prompted me to ask about
forming a new wg, but since I'd already said I'd AD sponsor
this on the list back in October, in fairness to the authors,
I'm gonna just go ahead for this one while we see how the
new-wg discussion pans out.

On 16/10/15 16:53, Stephen Farrell wrote:
> 
> So on the basis of a little positive feedback and it being
> fairly obvious I'll AD sponsor this one. I'll be working
> with the authors on that and an IETF LC should ensue in the
> not too distant (maybe just after IETF94). I'll send a mail
> here when that starts.
> 
> Cheers,
> S.
> 
> On 30/09/15 11:47, Stephen Farrell wrote:
>>
>> Folks,
>>
>> Carl and Max have asked me to AD sponsor this draft. Since it
>> seems like it's almost a bug fix, I'll probably go ahead and
>> do that if there are no significant objections here in the next
>> couple of weeks (say by Oct 15).
>>
>> So if you care about EST, please take a look (it's only 8 pages)
>> and say what you think.
>>
>> Thanks,
>> Stephen.
>>
>> On 04/08/15 12:34, Carl Wallace wrote:
>>> The draft referenced below may be of interest to some on this list. It
>>> defines some new OIDs to disambiguate existing EST challengePassword
>>> attribute usage from PKCS #9/legacy usage and defines a new OID to convey
>>> a one-time password as an additional value or alternative to the
>>> tls-unique mechanism defined in EST.
>>>
>>> On 8/3/15, 2:35 PM, "[email-masked]" <[email-masked]>
>>> wrote:
>>>
>>>>
>>>> A new version of I-D, draft-wallace-est-alt-challenge-00.txt
>>>> has been successfully submitted by Carl Wallace and posted to the
>>>> IETF repository.
>>>>
>>>> Name:		draft-wallace-est-alt-challenge
>>>> Revision:	00
>>>> Title:		Alternative Challenge Password Attributes for Enrollment over
>>>> Secure Transport
>>>> Document date:	2015-08-03
>>>> Group:		Individual Submission
>>>> Pages:		9
>>>> URL:            
>>>> https://www.ietf.org/internet-drafts/draft-wallace-est-alt-challenge-00.tx
>>>> t
>>>> Status:         
>>>> https://datatracker.ietf.org/doc/draft-wallace-est-alt-challenge/
>>>> Htmlized:       
>>>> https://tools.ietf.org/html/draft-wallace-est-alt-challenge-00
>>>>
>>>>
>>>> Abstract:
>>>>   This document defines a set of new Certificate Signing Request
>>>>   attributes for use with the Enrollment over Secure Transport (EST)
>>>>   protocol.  These attributes provide disambiguation of the existing
>>>>   overloaded uses for the PKCS #9 challengePassword attribute.  Uses
>>>>   include the original certificate revocation password, common
>>>>   authentication password uses, and EST defined linking of transport
>>>>   security identity.
>>>>
>>>>                  
>>>>        
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>>
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Carl Wallace <[email-masked]>
Date: Sat, 06 Feb 2016 10:19:41 -0500

>for it, that'll be fine but I wanted to ask.)

I don't think it's really needed. Even with a mechanism ID for either of
those referenced RFCs, context may dictate validator behavior in ways not
reflected by a mechanism ID. Tying OTP generator/validator behavior to
this attribute would be a big increase in scope. Were a mechanism ID ever
needed, it could be added as a peer attribute without requiring change to
a widely used structure.

>different uses clear as they read.

Can this be handled as a last call comment?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Feb 2016 13:17:26 +0000

> needed, it could be added as a peer attribute without requiring change to

Fair enough.

> Can this be handled as a last call comment?

Absolutely, it's just a nit really.

>> start IETF LC for this one.

I've asked for IETF LC now, you should see the message in a
while,

Cheers,
S.