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

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Sep 2015 11:47:10 +0100

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

---

From: Sean Turner <[email-masked]>
Date: Wed, 30 Sep 2015 22:16:10 -0400

Short to the point - seems like a fine candidate to AD sponsor.  Only one question/comment: 

Don't you need to say which of the DirectoryString choices you’ve got to support.  In other words, don’t you need to include something along the following lines (similar to what’s in RFC 2985):

   These attribute values generated in accordance this document
   SHOULD use the PrintableString encoding whenever possible.
   If internationalization issues make this impossible, the UTF8String
   alternative SHOULD be used.  Attribute processing systems MUST
   be able to recognize and process all string types in DirectoryString
   values.

Note I’m not suggesting the above is correct just that it’s similar to what’s in RFC 2985.

spt

On Sep 30, 2015, at 06:47, Stephen Farrell <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 1 Oct 2015 03:08:00 +0000

> On Sep 30, 2015, at 8:16 PM, Sean Turner <[email-masked]> wrote:
> 

RFC7030 states that "the resulting string is placed in the certification request challenge-password field ([RFC2985], Section 5.4.1)” which includes a copy of this paragraph (with very slight variations). 

I see no problem either repeating this text or making the reference to RFC2985 more explicit.

- max