ietf-smime
[Top] [All Lists]

Comments on certificate handling draft

1998-06-08 14:38:55
          Below are comments to the cert handling draft. Most of them 
          are editorial in nature. I really haven't been following 
          this draft so I may have made some improper assumptions. Use 
          them for what they're worth.
          
                                bill
          
          - clause 3.1 seemed to be placing quite a bit under the 
          heading of DN for Internet mail. I've made the following 
          assumptions: the section is really Using Internet Mail for 
          DN; the section was addressing using an e-mail address in 
          place of the Extension.subject DN; the section was 
          addressing how receiving agents handle using e-mail as a DN. 
          Below is recommended text. In it the Issuer and Subject 
          names were moved out of section 3.1 to the more generic 
          section 3.0, and added a clause that when using the email as 
          DN the Extension.subject field should be empty, 
          
          
          3. Distinguished Names in Certificates
          
          Issuer names MUST be populated (i.e. not an empty SEQUENCE) 
          in S/MIME-compliant v3 X.509 Certificates.
          
          Subject names MUST be populated in S/MIME-compliant v3 X.509 
          Certificates, unless identity information is present only in 
          the subjectAltName extension (see 4.4.3) in which case the 
          subject may contain an empty SEQUENCE. In the latter case 
          the subjectAltName extension MUST be marked as critical. 
          
          3.1 Using Internet Mail for Distinguished Names 
          
          End-entity certificates MAY contain an Internet mail address 
          as described in [RFC-822]. The address MUST be an 
          "addr-spec" as defined in Section 6.1 of that specification. 
           The email address SHOULD be in the subjectAltName 
          extension.
          
          When used as a subject identifier, email addresses SHOULD 
          NOT be in the subject distinguished name. The subject 
          distinguished name SHOULD instead contain an empty SEQUENCE.
          
          Receiving agents MUST recognize email addresses in the 
          certificate subjectAltName extension. While using email 
          addresses in the certificate subject field is not 
          recommended by this document, receiving agents MUST be able 
          to recognize email addresses in the subject Distinguished 
          Name field.
          
          Sending agents SHOULD make the address in the From or Sender 
          header in a mail message match an Internet mail address in 
          the signer's certificate. Receiving agents MUST check that 
          the address in the From or Sender header of a mail message 
          matches an Internet mail address in the signer's 
          certificate, if mail addresses are present in the 
          certificate. A receiving agent SHOULD provide some explicit 
          alternate processing of the message if this comparison 
          fails, which may be to display a message that shows the 
          recipient the addresses in the certificate or other 
          certificate details.
          
          - I thought that section 4.4 was a little wordy and 
          redundant. Below is recommended text which express the 
          following: changed "X.509 v3 standard" (never saw it 
          expressed like that); and the draft called out a " minimum 
          required set" of extensions but doesn't say what it is (I 
          made the assumption that it was the 5 extensions that the 
          agents were required to handle) and that although "minimum 
          required" would suggest a MUST the later definition of the 
          extensions suggested that it was a SHOULD. 
          
          4.4 X.509 Version 3 Certificate Extensions
          
          The X.509 standard [X.509] describes an extensible framework 
          in which the basic certificate information can be extended 
          and how such extensions can be used to control the process 
          of issuing and validating certificates. The PKIX Working 
          Group has ongoing efforts to identify and create extensions 
          which have value in particular certification environments. 
          As such, there is still a fair amount of profiling work to 
          be done before there is widespread agreement on which v3 
          extensions will be used. Further, there are active efforts 
          underway to issue X.509 v3 certificates for business 
          purposes. 
          
          At a minimum, the basicConstraints, keyUsage, 
          authorityKeyID, subjectKeyID, and the subjectAltNames X.509 
          v3 certificate extensions, defined in [X.509], SHOULD be 
          supported. Other X.509 v3 certificate extensions MAY also be 
          supported. Unless the extension is deemed critical for 
          correct interpretation of the associated certificate or 
          otherwise noted in this document, all extensions SHOULD be 
          marked as non-critical.
          
          Sending and receiving agents MUST correctly handle the v3 
          Basic Constraints Certificate Extension, the Key Usage 
          Certificate Extension, authorityKeyID, subjectKeyID, and the 
          subjectAltNames when they appear in end-user certificates. 
          Some mechanism SHOULD exist to handle the defined v3 
          certificate extensions when they appear in intermediate or 
          CA certificates.
          
          Unless otherwise specified in this document, interpretation 
          and syntax for all extensions MUST follow [KEYM].
          
          - clause 4.4.1 - 4.4.3: address 3 of the 5 recommended 
          extensions in more detail (i.e. basicConstraints, keyUsage, 
          and subjectAltNames) were the other two (authorityKeyID and 
          subjectKeyID) omitted for a reason? Recommend giving the 
          criticality of all of the extensions defined in these 
          sections in the same manner as 4.4.2.
          
          - clause 4.4.1: doesn't indicate whether the extension is 
          critical and one would assume based on earlier guidance in 
          the document that is should be non-critical (by default). 
          Recommendations from both X.509 (1997) and the PKIX profile 
          would seem to suggest that this should be a critical 
          extension. 
          
          
          -clause 4.4.3: suggest restating guidance on criticality of 
          subjectAltName expressed in section 3.1 here.
          
          

<Prev in Thread] Current Thread [Next in Thread>
  • Comments on certificate handling draft, Curtin, William <=