Subject: RE: Scope of PKIXML-WG. Was: Should PKIX protocols support XML w ell?

From: Michael Zolotarev <[email-masked]>
Date: Wed, 22 Nov 2000 20:34:50 +1100

> > I would certainly hope that IETF is the right place to 
> handle *this*. But
> > first we have to decide what exactly *this* is.
> 
> I have been encouraged to submit a BOF on this.  
> Unfortunately none of the area
> managers have responded to my request for action.  To 
> "settle" the scope
> should IMO not be done by those who do not intend to participate.
> 
Anders, before embarking on something which is not exactly within the
mainstream of the current PKI flow, we should be more than certain on the
exact scope of the undertaking. By looking at the recent discussion I could
see at least 3 possible 'scopes', with the only common thing - XML. I don't
think just saying "XML in PKI" is sufficient to form a WG. We have to be
more specific than that.
This is why I've outlined 1,2,3 in my previous message, and suggested that
(3) may have some rationale. 1 and 2 don't, IMO.

> 
> > Let me elaborate on the (3):
> > WHAT: Activity. Not a WG.
> 
> Why not?

If we accept that (3) is what we want to do, then there is not enough 'meat'
for a WG. It can be covered by existing (extended?) charter of AAA.

> 
> > WHERE: IETF AAA WG. I just think it'd be a right place for it.
> 
> I can't find any descriptions of the AAA WG. 

http://www.ietf.org/html.charters/aaa-charter.html

> 
> > Outside of PKIX, which maintains its purity and 
> concentrates on core protocols and
> > structures.
> 
> PKIXML would not nessesary be unpure.  Some PKIX's members 
> are undoubtly purists.

by saying 'pure' I mean PKC and closely related structures and protocols.
All in ASN.

> 
> > HOW: I can see two possible approaches here:
> > a) by doing it from scratch
> > b) by accommodating the work currently being done by vendor
> > consortiums.
> 
> a) Doing _what_ from scratch?

Defining XML-based Authentication framework starting from scratch, without
any relations to what's other have being doing.

> b) It can in some cases be done.  But rather seldom as the 
> consortiums usually
> are commercial and don't want interference.  S2ML, OBI, WAP, 
> IDENTRUS, SetCo etc. all
> belong to this category. 
I think that the attitude is changing. WAP came back to IETF with a proposal
to merge. The same with IDENTRUS - they want to stick to standards.

> From en engineer's point of view I 
> find it very uninspiring to to spend
> a lot of energy on nit-picking instead of being there when 
> the ground is made.  The discussions
> regarding ACs is an example of working in total darkness as 
> the questions really are: Does this work?
> Will it get generally (=MSFT) be supported?
> 
> AFAIK we have several possible work items for PKIXML
> - AC's 
> - Path validation protocols (I am not fully updated on these)
> 
I would suggest (not necessarily support, though, at that stage) to stick to
AC and authentication framework. Path validation protocols have enough
problems with scoping and defining boundaries and responsibilities. Encoding
is not the biggest of the concerns there.

> Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 22 Nov 2000 11:15:08 +0100

Michael,

> http://www.ietf.org/html.charters/aaa-charter.html

OK, I went through the description of their goals and it does IMO not match
the scope of my anticipated XML-AC.  RADIUS and network acess etc. is a rather
specific thing while ACs are not.

What I have tried to explain (in vain) is that ACs should be a self-contained (XMLDSIG)
signed containers having one of four different link styles to a Holder (none, named, PK, PKC).
And that the attribute part itself should be entirely app-specific.

That the path validation protocols have a lot of scope defintion problems is correct,
but there has been clear indication of a desire to use XML when these problems
have been resolved.

Bur right now the whole issue is a lost case as the only information we got, is that Steven Kent
want this stuff outside of PKIX.

I think that I pass on this until I see some action from the IETF area directors.

/Anders

---

From: [email-masked] (Terry Hayes)
Date: Wed, 22 Nov 2000 11:01:56 -0800

Anders Rundgren wrote:

> What I have tried to explain (in vain) is that ACs should be a self-contained (XMLDSIG) signed containers having one of four different link styles to a Holder (none, named, PK, PKC). And that the attribute part itself should be entirely app-specific.

You mean like this:  (paraphrased from the AC ID)

           AttributeCertificate ::= SEQUENCE {
                acinfo               AttributeCertificateInfo,
                signatureAlgorithm   AlgorithmIdentifier,
                signatureValue       BIT STRING
           }

           AttributeCertificateInfo ::= SEQUENCE {
                version              AttCertVersion DEFAULT v1,
                holder               Holder,
                issuer               AttCertIssuer,
                signature            AlgorithmIdentifier,
                serialNumber         CertificateSerialNumber,
                attrCertValidityPeriod   AttCertValidityPeriod,
                attributes           SEQUENCE OF Attribute
           }

           Holder ::= CHOICE {  -- modified!
                 baseCertificateID   [0] IssuerSerial,
                 entityName          [1] GeneralNames,
                 publicKeyDigest     [2] DigestInfo,
                 publicKeyCertDigest [3] DigestInfo
           }

           Attribute ::= SEQUENCE {
                 type      AttributeType,
                 values    SET OF AttributeValue
                   -- at least one value is required
           }

           AttributeType ::= OBJECT IDENTIFIER

           AttributeValue ::= ANY DEFINED BY AttributeType

           id-xml-attribute ::= { id-aca XX }
             -- attribute value SYNTAX is UTF8String, which is XML

Terry Hayes
[email-masked]