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 the Authority Clearance
Constraints certificate extension to indicate which clearance values
should be acceptable to relying parties.
=> correct
2
If the Clearance attribute
is present, it must contain a single value.
=> correct
2
SecurityCategory ::= SEQUENCE {
type [0]
TYPE-IDENTIFIER.&id({SupportedSecurityCategories}),
value [1]
EXPLICIT TYPE-IDENTIFIER.&Type
({supportedsecuritycategorie...@type})
}
=> correct
2
- classlist identifies the security classifications. Six basic
values are defined in bit positions 0 through 5 and more may be
defined by an organizational security policy.
=> correct
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.
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).
4
When
processing begins, permitted-clearances is initialized to the user
input value or special value all-clearances if Authority Clearance
Constraints user input is not provided.
=> correct
4
When processing the end PKC, the value in the Clearance attribute in
the end PKC is intersected with the permitted-clearances state
variable.
=> correct (note it is a case the value can be multiple)
4.1.1.2
If user input includes AuthorityClearanceConstraints, set the
permitted-clearances to the input value, otherwise,, set the
permitted-clearances to special value all-clearances.
=> correct
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)
4.1.1.5.1
Examine effective-clearance and verify that it does not contain more
than one value. If effective-clearance contains more than one value,
set effective-clearance to an empty list, set error code to "multiple
values", and exit with failure.
=> correct (the effective-clearance contains Clearance attribute)
but ambiguous: the effective-clearance is a list so it can have more
than one element (even there is no operation described in the document
which allows more than one element, IMHO it will be far better to
make effective-clearance a Clearance attribute or the special value
no-clearance (in place of empty list)).
4.1.1.5.1
If the permitted-clearances has special value of all-clearances, exit
with success.
=> correct
4.1.1.5.1
Assign those classList bits in effective-clearance a value of one (1)
that have a value of one (1) both in effective-clearance and in the
clearance structure in permitted-clearances associated with policyID
X. Assign all other classList bits in effective-clearance a value of
zero (0).
If none of the classList bits have a value of one (1) in effective-
clearance, set effective-clearance to an empty list and exit with
success.
=> correct
5
When processing begins, permitted-clearances
is initialized to user input or special value all-clearances if
Authority Clearance Constraints user input is not provided.
=> correct
5
When processing the AC, the value in the Clearance attribute in the
AC is intersected with the permitted-clearances state variable.
=> correct (possible multiple values)
6
If any of the Clearance attributes in the
AuthorityClearanceConstraints extension contains more than one value,
set effective-clearance to an empty list, set error code to "multiple
values", and exit with failure.
=> incorrect (no attribute, etc)
6
If the AuthorityClearanceConstraints certificate extension is not
present in the PKC, no action is taken, and the permitted-clearances
value is unchanged.
=> correct
6
If the AuthorityClearanceConstraints certificate extension is present
in the PKC and permitted-clearances contains the all-clearances
special value, then assign permitted-clearances the value of the
temp-clearances.
=> correct
6
If the AuthorityClearanceConstraints certificate extension is present
in the PKC and permitted-clearances does not contain the all-
clearances special value, take the intersection of temp-clearances
and permitted-clearances by repeating the following steps for each
clearance in the permitted-clearances state variable:
=> correct
6
-- For every classList bit, assign the classList bit a value of
one (1) for the policyID in permitted-clearances state
variable if the bit is one (1) in both the permitted-
clearances state variable and the temp-clearances for that
policyID; otherwise assign the bit a value of zero (0).
=> correct
7
2. If there is an element in SET B with the same Type OID and value
as in the element in SET A, carry out the following steps:
a) Add an element containing the Type OID and the value to the
SET temp-set.
b) Delete all elements with the same Type OID and the same
value from the SET B.
=> correct (securityCategories)
7
4. Perform Type OID specific intersection of the value in the
element in SET A with the values in the applicable elements in
SET B with the same Type OID.
=> correct (securityCategories)
7
5. If the intersection is not empty, add and element containing the
Type OID and intersection result as value to temp-set.
=> correct (BTW and element -> an element)
8
SecurityCategory ::= SEQUENCE {
type [0] OID id-TBSL,
value [1] BIT STRING
}
Note that Type specific intersection of two values for this Type will
be simply setting the bits that are set in both values. If the
resulting intersection has none of the bits set, the intersection is
considered empty.
=> correct
A
-- value [1]
=> correct
BTW the permitted-clearances type is loose, IMHO it is the sum of
AuthorityClearanceConstraints considered as a list of clearances
and the special value all-clearances. As it is not a certificate
extension, "set the permitted-clearances to AuthorityClearanceConstraints
certificate extension" is at least a short-cut (:-).
Regards
francis.dup...@fdupont.fr
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
