RE: Last Call: Qualified Certificates

["Nystrom, Magnus" <mnystrom@xxxxxxxxxxxxxxx>]

Jim,

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).

> 2.  Section 1 para 3: Remove all references to 1993 ASN.1

Russ has approved to keeping it (but, as we already do, keep the 1988
syntax normative). It will be 1997 ASN.1 syntax, BTW.

> 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.

> 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.

> 9.  Section 3.2.5.1 - I would like to know the reason that qcstatement-1
> has not been updated to a new OID.  This is a new draft document with
> some different semantics than 3039.  Are these changes all suffiently
> small that a new policy is not needed?

Thanks, we have discussed this and intend to assign a new OID.

> 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.

> 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