RE: SCVP 16 comments deadline

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> Hi Peter,
> You are assuming that there is only one possible matching algorithm for
> a name type - which seems a fragile assertion. The be more  robust then
> you supply a name and a matching rule identifier - which is what the
> name validation algorithm does.
I am not assuming a single possible matching algorithm. 
I'd am saying that there should be at least
one matching algorithm that can compare any name (probably at least
binary comparison). 

> I have seen examples of cases where a name has been inserted into an asn
> structure which does not cause an ASN decode error but the name is still
> bad because the name semantics are wrong - so I don't subscribe to the
> notion that all bad names cause asn decode errors.

Do you mean 'additional syntactical constraints' or really 'semantics'?

Syntactical errors include dection like 'an rfc822 has an @ sign etc'.
Semantical sounds to me like you want validate whether the email exists, whether
domain exists, etc.?

Syntactical errors can provokde asn1 decoding errors, it depends also
to a certain degree on what version of ASN1 you use in order to
directly specify constraints... ooups, I think is currently
forbidden to talk at all about ASN1 version in PKIX. So I break the
rule. make a ASN1 syntax which is valid under a CURRENT version, please.  

Anyway, having a special error code doesn't hurt too much.


> 
> * -----Original Message-----
> * From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
> * Sent: Thursday, December 09, 2004 4:58 AM
> * To: Peter.Sylvester@xxxxxxxxxx; Trevor Freeman
> * Cc: ietf-pkix@xxxxxxx
> * Subject: RE: SCVP 16 comments deadline
> * 
> * 3.1.5.2.3 Name Validation Algorithm
> * 
> * I find the possibilities for the Name Validation Algorithm
> * rather unsafisfying.
> * 
> * It should be possible IMO to have a matching simply by
> * presenting whatever form of Generalname and this should
> * be compared with the corresponding value in the cert.
> * 
> * In fact, the id-svp-dnValAlg sounds rather restrictive to
> * me, it seems to imply that only the subject field is
> * compared (or does this also compare with the Dirname in
> * a subjectAltname).
> * 
> * This restriction about a DN doesn't seem necssary to me,
> * Any generalName can be compared with any in the subjectAltname.
> * 
> * E.g. an IP address.
> * 
> * 'id-nvae-unknown-pupose'   ==> 'id-nvae-unknown-purpose'
> * 
> *   id-nvae-name-mismatch vs   The id-nvae-nameMismatch value
> [TF] Fixed
> * 
> * please align the spellings of all the errors types.
> * 
> *   The id-nvae-badName value means the client supplied either and
> *   empty or malformed name in the request.
> * 
> * what is a bad or malformed name? How can this happen without raising
> * a general asn1 decoding error
> * 
> * since it comes right next?
> * 
> * ---
> * cleanup the following text, please
> * 
> *   The userPolicySet item specifies a list of policy identifiers that
> *   the SCVP server MUST use when forming and validating a certificate
> *   If certPolicies is not specified, then any-policy MUST be used.
> * 
> * 3.1.5.3 userPolicySet
> * 
> *   The userPolicySet item specifies a list of certificate policy
> *   identifiers that the SCVP server MUST use when constructing and
> *   validating a certification path.  If userPolicySet is not specified,
> *   then any-policy MUST be used.
> * 
> * 
> [TF] I will change the userPolicy set to the following
> The userPolicySet item specifies a list of certificate policy
> identifiers that the SCVP server MUST use when constructing and
> validating a certification path.
> 
> The requirement for use of the userPolicySet falling back to any-policy
> is being dropped because the referenced policy or the default policy
> will cover this.
> * 
>  
> Trevor
> 
>