Re: [Gen-art] review of draft-ietf-pkix-authorityclearanceconstraints-02.txt
Francis Dupont wrote: In your previous mail you wrote: Minor issues: - IMHO a transition paragraph is needed at the end of the Introduction in order to introduce technical dependencies: * clearance attribute is in fact from 3281bis (this is obvious when one reads the ASN.1 module appendix but it should be mentioned as soon as possible) I agree that's why it's in the last sentence of the 1st paragraph in the intro ;) = well, I missed it (:-). Well I missed your response. Somebody had to tell me to respond so we're even ;) The whole idea is to prepare a first reader (IMHO it is a problem when a document needs to be read more than once to get a good idea about what it specifies :-). - another issue is the multiple values in a Clearance attribute. The Clearance attribute syntax of section 2 is in fact for an AttributeValue type and doesn't include multiple values (only multiple SecurityCategory). Of course the Attribute in AC can contains multiple values, so the text often uses the term value in a very ambiguous way. We restrict the number of times clearance can be included in a certificate to one or zero. We also restrict it to be single valued. = this is what I understood but there are some places in the document where the term value is used about the clearance AttributeValue type, for instance inside AuthorityClearanceConstraints. Are you referring to the Authority Clearance Constraint extension that can include multiple values? = an extension can contain only one value embedded inside an OBJECT STRING, and it is forbidden (RFC 5280 4.2) to have multiple extensions with the same OID. So IMHO extensions and multiple values are exclusive. Okay now I get it. We'll work on a revision to address this. - 3 page 6: I don't understand this statement: In addition, each Clearance attribute in the SEQUENCE must not contain more than one value. perhaps SEQUENCE should be sequence (of AuthorityClearanceConstraints)? SEQUENCE refers to the ASN.1 construct for the extension. We didn't capitalize sequence previously so we'll switch it to lower case. Note the must ought to be MUST. = but a AuthorityClearanceConstraints contains clearances, no clearance attributes, so what does mean the more than one value? The sentence in question is going to get deleted. - 4.1.1.2 page 8: can't understand: If any of the Clearance attributes in the permitted-clearances contains more than one value This check makes sure there is only one value in permitted-clearances. = the permitted-value is either all-clearances or a AuthorityClearanceConstraints, so there is no Clearance attributes in it, nor a value... I think this will end up getting deleted too. - 4.1.1.5.1 page 9: in If the permitted-clearances has special value of all-clearances, exit with success. what about the effective-clearance (unchanged?) There's no need to set this value as it's the special case where it matches all. = the output is both the effective-clearance (with the - everywhere, including in 4.1.1.6) and success/failure, so all exists must specify both. I don't think we're going to change this one. effective-clearance has no meaning when it's set to all-clearances. - 8 page 15: what is id-TBSL? It stands for To Be Supplied Later. I guess now would be a good time ;) I need to get an OID from Russ we'll add this in the next version. = until you'll get one IMHO a comment should explain this (only TBD is recognized :-). Fair enough. To fix my main concern about the term value, as ASN.1 is not LISP (:-) I propose to typecheck all types where the term is used and to keep it when the type can contain a value (typically contain an attribute), remove it if it can't or replace it by SecurityCategory (or other?) if it is what you'd like to mean. We'll go through these to fix the ones that make sense after we incorporate the changes for the value text. francis.dup...@fdupont.fr PS: occurences of value: I delete the ones we got right ;) 3 The syntax for Authority Clearance Constraints certificate extension contains Clearance values that the CA or the AA asserts. = correct but IMHO misleading. I propose to remove the word values. Agreed 3 In addition, each Clearance attribute in the SEQUENCE must not contain more than one value. = incorrect (no attribute, lower case SEQUENCE, upper case must, no multiple values). Sentence to be deleted. 4.1.1.2 If any of the Clearance attributes in the permitted-clearances contains more than one value, set effective-clearance to an empty list, set error code to multiple values in input, and exit with failure. = incorrect (no attribute, no multiple value) Sentence to be deleted.
Re: [Gen-art] review of draft-ietf-pkix-authorityclearanceconstraints-02.txt
Francis, Good catch on Authority Clearance Constraints not asserting clearance as an attribute. We are fixing the I-D. -Original Message- From: francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Sent: Sunday, August 16, 2009 12:44 PM To: Sean Turner Cc: gen-art@ietf.org; Santosh Chokhani; tim.p...@nist.gov Subject: Re: review of draft-ietf-pkix-authorityclearanceconstraints-02.txt In your previous mail you wrote: Minor issues: - IMHO a transition paragraph is needed at the end of the Introduction in order to introduce technical dependencies: * clearance attribute is in fact from 3281bis (this is obvious when one reads the ASN.1 module appendix but it should be mentioned as soon as possible) I agree that's why it's in the last sentence of the 1st paragraph in the intro ;) = well, I missed it (:-). * the processings augment the RFC 5280 section 6 (so the text is understable only with this section in mind) It says this in section 4.1 and 5.1, but we could move something to the intro to explain that we're augmenting the 5280/3281bis processing rules. How about: This document augments the certification path validation rules for PKCs in [RFC5280] and ACs in [RFC3281bis]. = fine The whole idea is to prepare a first reader (IMHO it is a problem when a document needs to be read more than once to get a good idea about what it specifies :-). - another issue is the multiple values in a Clearance attribute. The Clearance attribute syntax of section 2 is in fact for an AttributeValue type and doesn't include multiple values (only multiple SecurityCategory). Of course the Attribute in AC can contains multiple values, so the text often uses the term value in a very ambiguous way. We restrict the number of times clearance can be included in a certificate to one or zero. We also restrict it to be single valued. = this is what I understood but there are some places in the document where the term value is used about the clearance AttributeValue type, for instance inside AuthorityClearanceConstraints. Are you referring to the Authority Clearance Constraint extension that can include multiple values? = an extension can contain only one value embedded inside an OBJECT STRING, and it is forbidden (RFC 5280 4.2) to have multiple extensions with the same OID. So IMHO extensions and multiple values are exclusive. - 3 page 6: I don't understand this statement: In addition, each Clearance attribute in the SEQUENCE must not contain more than one value. perhaps SEQUENCE should be sequence (of AuthorityClearanceConstraints)? SEQUENCE refers to the ASN.1 construct for the extension. We didn't capitalize sequence previously so we'll switch it to lower case. Note the must ought to be MUST. = but a AuthorityClearanceConstraints contains clearances, no clearance attributes, so what does mean the more than one value? - 4.1.1.2 page 8: can't understand: If any of the Clearance attributes in the permitted-clearances contains more than one value This check makes sure there is only one value in permitted-clearances. = the permitted-value is either all-clearances or a AuthorityClearanceConstraints, so there is no Clearance attributes in it, nor a value... - 4.1.1.5.1 page 9: in If the permitted-clearances has special value of all-clearances, exit with success. what about the effective-clearance (unchanged?) There's no need to set this value as it's the special case where it matches all. = the output is both the effective-clearance (with the - everywhere, including in 4.1.1.6) and success/failure, so all exists must specify both. - 8 page 15: what is id-TBSL? It stands for To Be Supplied Later. I guess now would be a good time ;) I need to get an OID from Russ we'll add this in the next version. = until you'll get one IMHO a comment should explain this (only TBD is recognized :-). To fix my main concern about the term value, as ASN.1 is not LISP (:-) I propose to typecheck all types where the term is used and to keep it when the type can contain a value (typically contain an attribute), remove it if it can't or replace it by SecurityCategory (or other?) if it is what you'd like to mean. francis.dup...@fdupont.fr PS: occurences of value: Abstract The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), CA public key certificates, and an Attribute Authority (AA) public key certificate in a public key certification path constrain the effective Clearance of the subject. =
Re: [Gen-art] review of draft-ietf-pkix-authorityclearanceconstraints-02.txt
In your previous mail you wrote: Minor issues: - IMHO a transition paragraph is needed at the end of the Introduction in order to introduce technical dependencies: * clearance attribute is in fact from 3281bis (this is obvious when one reads the ASN.1 module appendix but it should be mentioned as soon as possible) I agree that's why it's in the last sentence of the 1st paragraph in the intro ;) = well, I missed it (:-). * the processings augment the RFC 5280 section 6 (so the text is understable only with this section in mind) It says this in section 4.1 and 5.1, but we could move something to the intro to explain that we're augmenting the 5280/3281bis processing rules. How about: This document augments the certification path validation rules for PKCs in [RFC5280] and ACs in [RFC3281bis]. = fine The whole idea is to prepare a first reader (IMHO it is a problem when a document needs to be read more than once to get a good idea about what it specifies :-). - another issue is the multiple values in a Clearance attribute. The Clearance attribute syntax of section 2 is in fact for an AttributeValue type and doesn't include multiple values (only multiple SecurityCategory). Of course the Attribute in AC can contains multiple values, so the text often uses the term value in a very ambiguous way. We restrict the number of times clearance can be included in a certificate to one or zero. We also restrict it to be single valued. = this is what I understood but there are some places in the document where the term value is used about the clearance AttributeValue type, for instance inside AuthorityClearanceConstraints. Are you referring to the Authority Clearance Constraint extension that can include multiple values? = an extension can contain only one value embedded inside an OBJECT STRING, and it is forbidden (RFC 5280 4.2) to have multiple extensions with the same OID. So IMHO extensions and multiple values are exclusive. - 3 page 6: I don't understand this statement: In addition, each Clearance attribute in the SEQUENCE must not contain more than one value. perhaps SEQUENCE should be sequence (of AuthorityClearanceConstraints)? SEQUENCE refers to the ASN.1 construct for the extension. We didn't capitalize sequence previously so we'll switch it to lower case. Note the must ought to be MUST. = but a AuthorityClearanceConstraints contains clearances, no clearance attributes, so what does mean the more than one value? - 4.1.1.2 page 8: can't understand: If any of the Clearance attributes in the permitted-clearances contains more than one value This check makes sure there is only one value in permitted-clearances. = the permitted-value is either all-clearances or a AuthorityClearanceConstraints, so there is no Clearance attributes in it, nor a value... - 4.1.1.5.1 page 9: in If the permitted-clearances has special value of all-clearances, exit with success. what about the effective-clearance (unchanged?) There's no need to set this value as it's the special case where it matches all. = the output is both the effective-clearance (with the - everywhere, including in 4.1.1.6) and success/failure, so all exists must specify both. - 8 page 15: what is id-TBSL? It stands for To Be Supplied Later. I guess now would be a good time ;) I need to get an OID from Russ we'll add this in the next version. = until you'll get one IMHO a comment should explain this (only TBD is recognized :-). To fix my main concern about the term value, as ASN.1 is not LISP (:-) I propose to typecheck all types where the term is used and to keep it when the type can contain a value (typically contain an attribute), remove it if it can't or replace it by SecurityCategory (or other?) if it is what you'd like to mean. francis.dup...@fdupont.fr PS: occurences of value: Abstract The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), CA public key certificates, and an Attribute Authority (AA) public key certificate in a public key certification path constrain the effective Clearance of the subject. = correct 1 Organizations that have implemented a security policy can issue certificates that include an indication of the clearance values held by the subject. = correct 1 Some organizations have multiple TAs, CAs, and/or AAs and these organizations may wish to indicate to relying parties which clearance values from a particular TA, CA, or AA should be accepted. = correct 1 a security policy has been defined for Amoco with three security classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and = correct 1 Cross-certified domains can also make use of
