RE: Last Call: Qualified Certificates

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

Jim,

Thanks for continuing the discussion... Some replies below.

On Wed, 17 Dec 2003, Jim Schaad wrote:

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

Well, it is not important for me. I just wanted to follow the example set
by 2459/3280.

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

No - ISO 8825-1 says that you can have any precision when DER-encoding
GeneralizedTime values, but seconds MUST be present (as must the "Z" for
UTC time). Trailing decimal zeros are always removed. I.e. an authority
which only uses dates will have values like:

19601217000000Z

Whereas an authority which does count seconds may have

19601217000022Z

But this would not be allowed:

19601217000022.0Z

Note that, in all cases, the string will consist of at least 15
characters. Any more than that an the authority uses fractional seconds
down to the precision allowed by ISO 8601. I still don't think this needs
to be specified further.

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

Right, it is a little harder (but not particularly complex). On this one -
and also to answer Russ comment as to why I would like to allow both
variants - I am concerned about backwards-compatibility. 3039 has been out
for a couple of years now and both patterns may have been used.

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

No, that was not the intent - this document should not be a name
registration authority.

Note the syntax: A QCStatement is a SEQUENCE of a statementID component
(an OID) and an optional statementInfo. For the object qcStatement-1, the
statementInfo component is a value of type SemanticsInformation. The
semantics of qcStatement-1 is that the certificate has been issued in
conformance with syntax and semantics identified in this document. In the
case of qcStatement-1, the statementInfo component (which is of type
SemanticsInformation) "MAY contain a semantics identifier and MAY identify
one or more name registration authorities." ("MAY" since the components
are optional).

As stated in the document, the semanticsIdentifier component of a
SemanticsInformation value contains an OID which defines semantics for
certain attributes and names in basic certificate fields, and the
nameRegistrationAuthorities component contains the name of one or more
authorities responsible for the registration of attributes or names
associated with the subject and the association between such an authority
and present attributes MAY be defined by a semanticsIdentifier OID.

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

As I see it, you shouldn't. The statementInfo component is optional. If
all you want to say is that you're conformant with syntax and semantics of
this document then you set the statementID to id-qcs-pkixQCSyntax-v1 and
leave out the statementInfo component. If there is some well-known OID
that defines semantics for a set of attributes and/or names used then
include the statementInfo component, and set the semanticsIdentifier
component. If you just want to name a registration authority then include
the statementInfo component and set its nameRegistrationAuthority
component. If you want to associate a name a registration authority with
semantics for certain attributes then set both components of the
SemanticsInformation.

I have tried to capture our thinking above, but I may have missed
something as we wrote this almost four years ago. Stefan, feel free to
correct me if I got something wring.

Did this help at all, Jim?

-- Magnus