[OGSA-AUTHZ] Updated version of VOMS Specification (FINAL)
David Chadwick
d.w.chadwick at kent.ac.uk
Mon Sep 11 08:30:14 CDT 2006
Hi Vincenzo
concerning point v) you misunderstood my point. I was actually saying
that your example should include (OID 1 3 6 1 5 5 7 1 14) since this
signals that the cert is a proxy cert, but your example does not appear
to include it, therefore your example cant be a proper proxy cert.
regards
David
Vincenzo Ciaschini wrote:
> David Chadwick wrote:
>
>> Hi Vincenzo
> Hi David,
>
>>
>> I was looking though your document and I have the following comments
>> to make
>
> In general: Thanks for all your comments!
>
>>
>> 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
> Oops! The one in the example is the correct one. I'll fix the one in
> section 3.
>
>>
>> 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.
> The intent of this extension is to include the AA's PKC and its 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.
> We will clarify this.
>
>>
>> iii) Section 3.5.4.1 "the MUST" -> "they MUST"
> Corrected.
>
>>
>> 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.
> Ok, I see this needs to be clarified. In short, the ACs are packages
> inside the AC sequence defined in Section 4.1. We will rewrite this to
> make it clearer.
>
> Also, policy language values are supposed to be those specified in RFC
> 3280, section 3.8.2, as is standard for proxy certificates. For these
> we did not think about duplicating the information.
>
>
>>
>> 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.
> Where is this? I just checked the doc, and the nearest match to that
> was (1 3 6 1 5 5 7 1 1), authorityInfoAccess.
>
>>
>> vi) the example contains the OID 1 3 6 1 4 1 8005 100 100 11 which is
>> not described anywhere
> Corrected (an old value was present in the OID of the tags extension.
>>
>> vii) the example contain the OID 1 3 6 1 4 1 8005 100 100 6 which is
>> obsoleted in Section 4.3
> Yes, it is there intentionally, to demonstrate that it is possible to
> find them (for compatibility with older servers), but they should be
> ignored.
>
>>
>> viii) section 3.4.1. The IetfAttrSyntax is defined in RFC 3281 and not
>> RFC 3280.
> Oops!
>
> I will send an updated version as soon as you can direct me to where is
> point v)
>
> Thanks for your comments,
> Vincenzo
>
>>
>>
>> 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