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
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. (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. (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. 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. (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. Regards, Blair
-----Original Message----- From: owner-ogsa-authz@ggf.org [mailto:owner-ogsa-authz@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
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@ggf.org [mailto:owner-ogsa-authz@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
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@ggf.org [mailto:owner-ogsa-authz@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
Vincenzo, 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? 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. 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.
(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
But the RFC recommends that only one should be used. Done. 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@ggf.org [mailto:owner-ogsa-authz@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>
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@ggf.org [mailto:owner-ogsa-authz@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>
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@ggf.org [mailto:owner-ogsa-authz@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
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@ggf.org > [mailto:owner-ogsa-authz@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg -- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************
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@ggf.org >> [mailto:owner-ogsa-authz@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
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@ggf.org >>> [mailto:owner-ogsa-authz@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************
David Chadwick wrote:
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.
Ah! Yes, I indeed misunderstood. However, the reason why 1.3.6.1.5.5.7.1.14 is missing is explained in the initial part of section 5: "Please note that for simplicity, this is a Globus Toolkit 2-compatible proxy certificate." This because the intent of the example is to show the new VOMS-specific extensions, without confusing the issue with the many other extensions defined in RFC 3820. That's why the ProxyCertInfo extension is absent. Because it is not required in GT2 proxies. Ciao, Vincenzo
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@ggf.org >>>> [mailto:owner-ogsa-authz@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
Vincenzo Ciaschini wrote:
David Chadwick wrote:
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.
Ah! Yes, I indeed misunderstood. However, the reason why 1.3.6.1.5.5.7.1.14 is missing is explained in the initial part of section 5:
"Please note that for simplicity, this is a Globus Toolkit 2-compatible proxy certificate."
This because the intent of the example is to show the new VOMS-specific extensions, without confusing the issue with the many other extensions defined in RFC 3820. That's why the ProxyCertInfo extension is absent. Because it is not required in GT2 proxies.
Hi Vincenzo From a standards perspective this is an oxymoron, since there is only one standard way of declaring a certificate to be a proxy, and that is via the standard proxy extension, which you say is not required. No matter. It would also be good to say how your extensions work for standard proxy certs as well as for GT2 nonstandard ones. I take it that your chain of ACs are designed to be embedded directly into PKCs in their own extension, rather than being embedded inside the proxy extension as the policy language. I initially thought that the OID you had defined might be meant to be the policy language OID of the proxy extension, rather than a PKC extension OID, so that the AC chain was embedded inside the proxy cert extension. regards David
Ciao, Vincenzo
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@ggf.org >>>>> [mailto:owner-ogsa-authz@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************
participants (5)
-
Blair Dillaway -
David Chadwick -
Mary Thompson -
Vincenzo Ciaschini -
Von Welch