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
Re: [Gen-art] Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05
>> If so, can it generate illegal sieve scripts >> from the XML? How can it avoid doing so if it doesn't have a semantic >> knowledge of sieve? > > Nowhere does this document say or even imply that no semantic > knowledge of > Sieve is required to construct a Sieve from scratch using the XML > representation. Such a claim would be absurd in any case - it is > axiomatic that > in order to construct a program you have to know what the elements > in the > language do! > > What the document does say (section 4.1, fourth paragraph) is that > XML can be > used to avoid the need for a client to understand sieve *grammar* or > to have a > full understanding of Sieve semantics. Syntax understanding is made > unnecesary > by substituting XML syntax, of course. As for semantics, a processor > can be > written (and many have been) that only look at the metadata elements > (displayblock and so on) and treat all the Sieve stuff under those > elements as > a black box. I inferred from that very paragraph imply that the "editor" was not necessarily expected to understand sieve semantics. Then I'm afraid you didn't read it very carefully. What is says is clients don't necesarily need _complete_ knowledge. Again, it is axiomatic that *some* knowledge of Sieve semantics is going to be necessary. But lots of editors operate on the basis of templates containing sequences of Sieve commands. They only have enough knowledge to stitch the templates together, and such manipulations may be simpliified through the use of the XML format. If that is not the intent, It most certainly is the intent. it would be helpful to have a sentence or two somewhere (maybe in the intro) to explicitly say so. My confusion might be around the meaning of the term "client" in this context. No, I think your confusion is that you read a lot more into the text than it actually says. There's a pretty big difference between "no semantic understanding whatsoever" and "an incomplete semantic understanding'. Is the expectation that an "editor" must be semantically aware of sieve, but a processor does not (beyond the list of "controls")? The expectation is that the amount of semantic understanding an editor is going to need will very much depend on the range of operations the editor is able to perform. Simple template-based systems will only manipulate labelled blocks of Sieve code without any understanding of what that code does. A more sophisticated editor might need to have a detailed knowledge of how blocks in Sieve work, or how to build conditional expressions, or even the details sematics of various tests and actions. ... Instead of round trip "conversion", I should have said round-trip "editing". My concern is, if I create a script using Editor A, then later edit it with Editor B, any metadata created by Editor A is likely to be lost. And that's a valid concern to have. Again, there are going to be cases where one editor has no choice but to strip the information added by another. This is simply how things are; there's nothing this or any other representation scheme can do to eliminatte this possibility. Is that the intent? It's not a matter of intent. It is simply an unavoidable reality. If so, it's probably worth mentioning that an editor needs to be able to deal rationally with the loss of its own metadata. First, while it is certainly desireable for all editors to have this characteristic, there are going to be cases where it cannot possibly work this way. So this can't be a requirement. Second, even if it were appropriate to make this a requirement, this document isn't the place for it. All this document does is describe an XML representation for Sieve. All of the requirements it imposes are directed at the representation and the process of converting to or from that representation. But since there is no requirement that a Sieve editor use this XML representation at all - and in practice most extant Sieve editors operate directly on the native Sieve format - imposing requirements on editors here makes little if any sense. (I can think of reasonable use cases that would involve this--perhaps I create the script with an editor on my laptop, but later need to modify it using an editor on a smart phone...). Again, there is absolutely no doubt that being able to use multiple editors on the same sieve and have them all work happily together is desireable. At a minimum I think it would be helpful to clarify that the "inconvenience" is around preserving metadata that the editor does not understand--i.e. metadata from a different metadata implementation. I think this is already pretty clear. >> Why not MUST? Wouldn't violation of this requirement introduce >> interoperability problems between different implementations? > > It's a SHOULD because the WG believed that there may be some > exception cases > where an alternate format makes more sense. Can you offer (in the text) some examples of those exceptional cas
