RE: Last Call: Qualified Certificates

["Jim Schaad" <jimsch@xxxxxxxxxx>]

> -----Original Message-----
> 
> Thanks for your review. I'll respond to a few of your 
> comments here. Stefan will address the others.
> 
> On November 12, Jim Schaad wrote:
> 
> > Comments on this draft are as follows:
> >
> > 1.  Section 1 para 3;  I object to the phrase "private extensions". 
> > This document does not defined private extensions even if 
> they exist 
> > in the id-pe arc.  These are now public extensions. -- 
> Remove the word 
> > private.
> 
> No, we are using the branch id-pe which specifically is named 
> "arc for private certificate extensions" in RFC 3280. As I 
> see it, private/public refers to presence in X.509 or not. 
> C.f. section 4.2.2 of RFC 3280, whose title even is "Private 
> Internet Extensions" (although the TOC in RFC 3280 lists 
> another name).

I understand that it is under the private extensions arc.  I belive that
the way this arc was named is not clear.  IMHO by publishing this
extension in a public document for public consumption it no longer is a
private extension.  I see no advantage to having the word private in
this location.

> 
> > 6.  Section 3.2.1 - DateOfBirth SHOULD state the proper 
> encoding to be 
> > used.  I.E. are we looking for seconds, minutes or hours or 
> just DATE 
> > in the GeneralTime field?
> 
> I don't see a need to do this for interoperability reasons. 
> The GeneralizedTime ASN.1 type will always contain a date, 
> and optionally a time down to a precision as specified in ISO 
> 8601. Relying parties will need to parse the type anyway. 
> Some registration authorities may decide to use a more 
> precise measurement than others and I would not want to 
> preclude them from doing so.

In order to do a DER encoding of a GeneralTime field, without other
restraints being placed on this field, I think (but have not verified)
that on ewould be required to specify the msecs thus leading to a date
such as 196012170000000000Z for the DOB.  Even cutting it off at the
same level as dates in RFC3280 is an improvement.

> 
> > 7.  Section 3.2.1 - countryOfResidence and 
> countryOfCitizenship - If 
> > you have multiple countrys to be listed, should this be a 
> multi-value 
> > item or should there be two distinct attributes? 
> (Alternatively should 
> > this be restricted back to a single attribute with a single value - 
> > i.e you can only list one of your countries of citizenship.)
> 
> The attributes (seen as ASN.1 objects) themselves are 
> multi-valued. This follows from PKCS #9 v2.0 where they are 
> fully defined and we have a reference to PKCS #9 in the 
> document about this. But this still allows several distinct 
> attributes each with a single (or multiple) value (values). 
> As the extension itself only is intended to carry information 
> from a directory about the subject of the certificate and 
> does not disallow multiple instances of the same attribute 
> type it is really up to the issuer and the way it stores 
> information about the subject to populate it. A conformant 
> relying party that relies on information provided in this 
> extension will need to parse the complete extension value 
> anyway, so again I am not sure anything needs to be done.

This makes my code harder to implement as a RP.  I now need to look for
both multiple values and multiple fields.  It is much simplier to only
need to look for one (probably from ease of programing it would be
multiple values).

> > 10. Sectin 3.2.5.1 - I have decided to put the predefined statement 
> > into my QC.  After reading this document I understand that 
> what I want 
> > stearts as follows:
> >
> > 	EXTENSION { id-pe-qcStatements,
> > 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> > In this case I don't have asemanticsIdentifier created by the 
> > document, so I must be incoluding the NameRegistrationAuthorities 
> > otion.  However I don't know if what goes here is the pkix working 
> > group name or some other value.
> 
> I am not sure I understand your question Jim, but values for 
> the nameRegistrationAuthorities component has nothing to do 
> with PKIX. It is the OID for the authority responsible for 
> the subject's name (or attributes of the subject's name) as 
> it appears in the certificate. I thought this was clear from 
> 3.2.5.1?  Likewise for the semanticsIdentifier option - it is 
> to be specified by/for that authority.

LET ME QUOTE:

   --  This statement identifies conformance with syntax and
   --  semantics defined in this Qualified Certificate profile
   --  (Version 1). The SemanticsInformation may optionally contain
   --  additional semantics information as specified.

As I read this statement there should be an OID that identifies this
DOCUMENT as a name registration authority.  If I use the fields defined
by this document and use the defined OID in this document, then I need
to be able to correction encode this extension in my certificate without
reference to an external naming authority.  If this is not the case then
there is absolutely no reason to have section 3.1 or 3.2.1, 3.2.2, 3.2.3
or 3.2.4 as they are defining how these fields should be used.

I need a way to refer to this document as either the semanticsIdentifier
or the nameRegistrationAuthority.


> 
> > 11.  Sectin A.1 - I suggest changing the pretty name to 
> > PKIXqualified88-03 to distinquish from rfc3039.
> 
> I don't quite see why? Normally you keep the module name but 
> update the number (OID), and there are some reasons for this 
> too. C.f. X.509's "AuthenticationFramework" module whose name 
> has remained the same even though the module OID has changed 
> over the years. I believe the same is true for 
> "PKIX1Explicit88" too, for example.
> 
> -- Magnus
> 

jim