ietf-smime
[Top] [All Lists]

Mixed comments on smime-cert-02

1997-09-12 07:04:37

Some comments on draft-dusse-smime-cert-02.txt


The spec. is defined as the solution in the first paragraph of clause 
1. I see it as a solution, current praxis. The last sentence should 
read: "This draft describes a mechanisms S/MIME uses can use to 
create and validate keys using certificates."


In clause 4.4 are we referencing the draft X.509 v3 and the 
corresponding ISO/IEC 9594-8 amendment. These are now approved as a 
1997 publication, which we should refer to in appendix B. The notion 
of the Amendment could be kept in appendix B for convenience to 
readers, if it is believed to be useful.


There are MUST statements on CAs in clause 5.2. I do not believe that 
this spec. can enforce any CA policy. Change it to a SHOULD.


The following type of statements are copied from PKCS?9 in clauses 
5.2.1, 5.2.2 and 5.2.3 :
"It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL 
STRING), UnstructuredAddress will become a CHOICE type: 
UnstructuredAddress ::= CHOICE ?
    PrintableString, T61String, UNIVERSAL STRING ?"

UCS (which obviously :) should be understood as ISO 10646) has been 
approved and I expect us to only keep the CHOICE including the 
UNIVERSAL STRING.


Clauses 5.2.2 and 5.2.3 speaks about "PKCS ?6 extended certificates". 
The use of them are excluded according to 2.2.1, remove the 
references.


I would like a different approach in the second paragraph of clause 
6. 
a) If the cert. verification fails, present data with warning.
b) If the signature verification fails, present data with BIG warning 
or at least make data available by out of band means.


In appendix D - Revision History, it is stated "Removed [PEM] 
reference" but we still have MUST requirements on RFC 1422. What was 
the intention?


/Bengt Ackzell

<Prev in Thread] Current Thread [Next in Thread>
  • Mixed comments on smime-cert-02, Bengt . Ackzell <=