[OGSA-AUTHZ] Updated version of VOMS Specification (FINAL)

David Chadwick d.w.chadwick at kent.ac.uk
Sat Sep 9 17:36:35 CDT 2006 

Hi Vincenzo

I was looking though your document and I have the following comments to make

i) in Section 3 you say that the VOMS OID is 1.3.6.1.5.3004.100.100 but
in the examples it appears as 1 3 6 1 4 1 8005 100 100

ii) in Section 3.5.3 (issuerCerts) the name says this is an AC cert
list, but the semantics appears to say it is a PKC list up to but
excluding the root CA. Can you be more specific here please. Is this a
list of ACs from the AA (AC issuer) to the SOA, or is it a chain of PKCs
that are needed to validate the signatures on the ACs in the proxy cert.
Clearly it cant be both since in a delegation scenario there are
potentially many chains of PKCs, one for each AC issuer in the AC chain.
If it is meant to be a PKC chain, then the Semantics section should read
"This extension is meant to include the AA's public key certificate and
the whole public key certificate chain leading from it up to but
excluding the CA certificate..." and the syntax should be renamed
pk-cert-list.

iii) Section 3.5.4.1 "the MUST" -> "they MUST"

iv) in Section 4 you dont properly specify how your ACs are packaged
inside proxy certs, and I can not find what OID you have defined for the
policy language of a proxy cert. Is the AC sequence defined in Section
4.1 supposed to be it? or do you recommend using one of the standard
values of inherit all or independent? This needs to be spelt out more
clearly please.

v) In the example proxy cert in Section 5 I can not find the proxy cert
info extension (OID 1 3 6 1 5 5 7 1 14) anywhere.

vi) the example contains the OID 1 3 6 1 4 1 8005 100 100 11 which is
not described anywhere

vii) the example contain the OID 1 3 6 1 4 1 8005 100 100 6 which is
obsoleted in Section 4.3

viii) section 3.4.1. The IetfAttrSyntax is defined in RFC 3281 and not
RFC 3280.


regards

David


Mary Thompson wrote:
> Vincenzo,
>     I uploaded the version that was attached to your email to the 
> GridForge page for OGSA-AuthZ-wg 
> http://forge.gridforum.org/sf/go/projects.ogsa-authz/docman.root.attributes
> 
> Mary
> 
> Vincenzo Ciaschini wrote:
>> Von Welch wrote:
>>
>>> Vincenzo,
>> Hi Von,
>>
>>>  One question, according to 4.1.1 the extension id is { voms 5 },  but 
>>> looking at the example in section 5, I don't actually see that  
>>> extension used. What am I misunderstanding?
>> No, you are right.  What happened is that when I cut-and-pasted the AC 
>> dump, I mistakenly deleted that line.  This is fixed now.
>>>  One suggestion, the definition for the voms base oid is currently  
>>> somewhat buried in section 3.4.1.1, I suggest pulling that out and  
>>> making it more prominent.
>> Agreed.  It is now In section 3, right after the AC definition.
>>
>> Mary, since we consider the document final, can you upload it on the 
>> ogsa-authz page along the other documents for public access?  We don't 
>> seem to have access to do it ourselves.
>>
>> Ciao,
>>    Vincenzo
>>
>>> Von
>>>
>>> On May 31, 2006, at 8:18 AM, Vincenzo Ciaschini wrote:
>>>
>>>> Here it is included what is in our intention the final version of  
>>>> the document. There is only one change from the previous version.   
>>>> The attribute Tags has become the extension Tags, and has been  moved 
>>>> to the corresponding section.
>>>>
>>>> The reason for this is that adding an atribute cause backwards  
>>>> compatibility problems with some existing APIs to access the AC and  
>>>> so, in the interest of backwards compatibility, the data has been  
>>>> moved to an extension.
>>>>
>>>> Bye,
>>>>    Vincenzo
>>>>
>>>> Vincenzo Ciaschini wrote:
>>>>
>>>>> Blair Dillaway wrote:
>>>>>
>>>>>> Vincenzo,
>>>>>>
>>>>>> In reading this draft I've found a few places I believe would  benefit
>>>>>> from some additional clarification.
>>>>>>
>>>>>> (1) 3.1.1 - "As a consequence of this, in VOMS ACs the only
>>>>>> admissible choice for the field is the baseCertificateID."
>>>>>>
>>>>>> You might re-write this to say the holder field MUST include the
>>>>>> baseCertificateID field and omit the entityName and objectDigestInfo
>>>>>> fields. The syntax defines a sequence of 3 optional fields, not a
>>>>>> choice.
>>>>>>
>>>>> But the RFC recommends that only one should be used. Done.
>>>>>
>>>>>> (2) 3.4.1.2 - "Where <root group> is by convention the name of the
>>>>>> virtual organization."
>>>>>>
>>>>>> The document seems to imply this is a required encoding for
>>>>>> interoperability purposes. If so, its not just a convention. You
>>>>>> should clarify if this is a MUST, SHOULD, or RECOMMENDED encoding.
>>>>> Right, done.
>>>>>
>>>>>> (3) 3.4.1.2 - "Future compatibility issue: It is possible that in  the
>>>>>> future a /Role=NULL component may be omitted in its entirety.  The
>>>>>> same goes for a /Capability=NULL part.  Conforming applications
>>>>>> SHOULD be prepared to handle these cases."
>>>>>>
>>>>>> The previous paragraph states "The /Capability=<capability name>  part
>>>>>> is deprecated....". If so, I assume conforming implementations  SHOULD
>>>>>> always omit the /Capability part whether or not its null. Having it
>>>>>> be deprecated and noting it may disappear in the future seem to  be in
>>>>>> conflict.
>>>>> Unfortunately, that is the besr that ca be done for the moment,  
>>>>> since it should continue to be included until the software out  
>>>>> there has has a reasonable chance to change its implementation not  
>>>>> to rely on it. Obviously, this come free if the official APIs are  
>>>>> used.
>>>>>
>>>>>> Also the statement that /Role=NULL *may* be omitted in the future
>>>>>> seems to be in conflict with the examples in 3.4.1.3. The compact
>>>>>> format shown does omit Role=NULL. If this is allowed, then the 'in
>>>>>> the future' qualification should be removed. It should be stated if
>>>>>> the compact format is recommended, required, or simply a supported
>>>>>> encoding option.
>>>>>>
>>>>> The intent of the sentence is to state that applications  interested 
>>>>> in reading the date should deal with the case that the  field could 
>>>>> be empty.
>>>>>
>>>>>> (4) 3.4.2.2 - "A name-specific syntax that encodes multiple  values in
>>>>>> a single pair is also allowed."
>>>>>>
>>>>>> Examples of a single value and multiple value encoding would be
>>>>>> helpful here. The syntax in 3.4.2.1 indicates a Tag includes only a
>>>>>> single name, value, and qualifier field. I assume how multiple  values
>>>>>> are encoded into the value field should be specified for interop
>>>>>> purposes.
>>>>>>
>>>>> As said, it is name-specific, meaning that each attribute can  
>>>>> choose its own way.
>>>>>
>>>>>> Regards, Blair
>>>>> Bye,
>>>>>    Vincenzo
>>>>>
>>>>>>
>>>>>>> -----Original Message----- From: owner-ogsa-authz at ggf.org  
>>>>>>> [mailto:owner-ogsa-authz at ggf.org] On Behalf Of Vincenzo  Ciaschini 
>>>>>>> Sent: Friday, April 28, 2006 6:34 AM To: ogsa Authz  Subject:
>>>>>>> [OGSA-AUTHZ] Updated version of VOMS Specification
>>>>>>>
>>>>>>> Hi to All,
>>>>>>>
>>>>>>> This is the updated document about VOMS specification I promised
>>>>>>> yesterday.
>>>>>>>
>>>>>>> Apart from a few minor language clarifications, the main changes
>>>>>>> are in the following sections:
>>>>>>>
>>>>>>> 3.4.1  clarifications about the syntax of FQANs. 3.4.2  rewritten,
>>>>>>> with a (slight) change in format. 3.5.1  explanation rewritten.
>>>>>>> The previous explanation was the exact opposite of the truth. OOPS!
>>>>>>>
>>>>>>>
>>>>>>> Also, the AC example in section5 has been substituted with a more
>>>>>>> complete one.
>>>>>>>
>>>>>>> Bye, Vincenzo
>>>>>>>
>>>> <VOMSACv8.doc>
>>>
>> ------------------------------------------------------------------------
>>
>> --
>>   ogsa-authz-wg mailing list
>>   ogsa-authz-wg at ogf.org
>>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

More information about the ogsa-authz-wg mailing list