Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-00.txt

From: "Yee, Peter" <[email-masked]>
Date: Wed, 13 Feb 2002 11:39:13 -0800

Stephen,

>Glad to see someone's picked up on this topic. Coupla initial 
>comments:-

Sorry about the delay in responding -- sent out the drafts and then
disappeared off to a week's worth of training.  Bad timing!

>- Shouldn't this say that the ACs in question are to be conformant
>  to [ACPROF]? Presumably this'd also mean that some fields in this
>  spec have to obey the same profiling rules too, which sounds like
>  a good idea.

Agreed.  ACMC notes requirements about [ACPROF] compliance in a couple
of places.  I'll make sure that ACRMF points at ACPROF.

>- What's [ACMC] from november 2001? (Maybe its about to pop out?)

Seems it was delayed in posting, but has now come out.

>- The old LAAP protocol effectively allowed (the equivalent of) a regInfo
>  value to select the "type" of AC to be produced - this draft seems to
>  preclude that. Did I read it wrong or don't you think that's needed?

Are you referring to LAAP's LACRequestMessage profile values?  And yes,
this draft does not have a shortcut representation for a particular,
pre-agreed profile.  This could be a useful feature to incorporate,
although it might then compete more directly with LAAP.  That and it would
add to the complexity of essentially two different request types within
the protocol -- one the "flexible, specify all the attributes type" and the
other the "pre-defined, specify the profile" type.  I'm not against the
concept but would like to hear what other think.

>- Lastly, I never did come across a use case where a client would want
>  to specify a really complicated AttrCertTemplate - have you? Absent
>  that I'd have to say that this is maybe more complex than it needs
>  to be.

ACRMF was modeled to have nearly the same flexibility as found in CRMF.
So, that's the historical source of the complexity.  In terms of the need,
I have spoken with some potential users who wanted more flexibility, to
which
I finally acquiesced.  This protocol is intended to cover cases where LAAP
doesn't provide the on-the-fly flexibility that might be desired, at the 
obvious cost of complexity.  I think LAAP might be more appropriate for
cases where the ACs were of a well-defined nature and only needed generation
on-the-fly.

>Stephen.

							-Peter
							[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Feb 2002 11:12:14 +0000

Peter,

> Are you referring to LAAP's LACRequestMessage profile values?  

Yep.

> And yes,
> although it might then compete more directly with LAAP.  

What I was thinking was that if you did incorporate that nicely then 
there'd be no need for LAAP anymore (and since no-one seems to want 
to produce a new LAAP draft that'd be a happy outcome - if someone
does, let me know and I'll send you the source).

> That and it would
> I finally acquiesced.  

Fair enough, I guess though in hindsight the amount of flexibility
in CRMF was a mistake - there're probably still fields that no-one
can handle being populated in requests! (And *please*, let's not start
a thread on that!). 

> This protocol is intended to cover cases where LAAP

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com