RE: asn.1 modules in 3280bis
Sharon Boeyen <sharon.boeyen <at> entrust.com>
2007-02-02 14:18:26 GMT
I agree with Stephen.
I think it is too late to do this within the current document - agree that errors could be introduced. If others feel it is necessary to provide these modules (I have no need for them), I would prefer the second approach that was suggested (a separate small RFC that defined these).
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Stephen Farrell
Sent: Friday, February 02, 2007 7:01 AM
To: Stefan Santesson
Cc: Russ Housley; pkix
Subject: Re: asn.1 modules in 3280bis
I'd be marginally against this change, on the basis
that its so late, might be error prone and I'm not
sure that the claimed benefit is significant (don't
most people just comment out one of the colliding definitions?).
Having said that, if David (who'd do the work) does
want this, I won't object,
Stefan Santesson wrote:
> I would like to have the other editors and WG opinion.
> If it is positive, then I assume it's a fairly straightforward process
> if we get to it.
> Lets finish this up so we can ship this document.
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>> -----Original Message-----
>> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
>> pkix <at> mail.imc.org] On Behalf Of Russ Housley
>> Sent: den 29 januari 2007 18:02
>> To: Peter Sylvester; pkix
>> Subject: Re: asn.1 modules in 3280bis
>> RFC 3280 includes two ASN.1 Modules:
>> PKIX1Explicit88, and
>> I have no objection to using three ASN.1 Modules in 3280bis:
>> PKIX1Implicit88, and
>> I'm sure that you could help the authors figure out which type
>> definitions to move to the third module.
>> At 09:43 AM 1/29/2007, Peter Sylvester wrote:
>>> It may be a bit late but I would like to propose a small change RFC
>> 3280 bis.
>>> The text defines (as well as 3280) two ASN.1 modules. The
>>> two types of information:
>>> - rewrites from X.509 etc
>>> - new definitions like the id-pkix arc and extensions
>>> If one wants to use the new definitions in other specifications here
>>> the problem of ASN.1 compatibility when imported into other modules/
>>> I propose to add two modules:
>>> PKIXUsefulDefinitions which regroups definitions in such a way that
>>> they can be imported elsewhere. the syntax definitions for the
>>> private extensions. The actual
>>> PKIXExtensions in current syntax to use the
>>> EXTENSION CLASS to bind the extensions the OIDs.
>>> If this cannot be included into the 3280bis I propose a small RFC
>>> defining these modules.