Subject: Re: DER in ac509prof-03

From: [email-masked]
Date: Wed, 10 May 2000 11:12:45 -0400

The definition Phil referred to ("AttributeValue ::= ANY") should be
changed to
"AttributeValue ::= ANY DEFINED BY AttributeType", both here and in A.1 of
son-of-2459.  Since only SecurityCategory, among the structures specific to
AC509Prof, actually uses any old-fashioned formats, it would be better
either to include documentation of the 1993 format in the draft (as in 2459
and son-of-2459) or to change it to be compatible with INSTANCE OF.
Including documentation of the 1993 format would not break existing
implementations (if there are any), while changes to use INSTANCE OF would.

     Here are my suggestions (1-2 form the 1993 definition of the existing
SecurityCategory type with its own class, 3 is a 1993 definition of
SecurityCategory with the existing Attribute class, 4 is the 1988 version
of INSTANCE OF, 5 is the 1993 use of INSTANCE OF):

1)   SecurityCATEGORY               ::=     CLASS {
          &Type,
          &id  OBJECT IDENTIFIER UNIQUE }
     WITH SYNTAX { WITH SYNTAX &Type ID &id }

2)   SecurityCategory       ::=     SEQUENCE {
          type [0] IMPLICIT SecurityCATEGORY.&id,
          value     [1] EXPLICIT SecurityCATEGORY.&Type }

3)   SecurityCategory    ::=  SEQUENCE {
          type [0] IMPLICIT Attribute.&attributeId,
          value     [1] IMPLICIT Attribute.&attributeType    }

4)   SecurityCategory    ::=  [UNIVERSAL 8] IMPLICIT SEQUENCE {
          type OBJECT IDENTIFIER,
          value     [0] EXPLICIT ANY DEFINED BY type    }

5)   SecurityCategory    ::=  INSTANCE OF TYPE-IDENTIFIER

     Any corrections or suggestions are welcome.

          Tom Gindin

Stephen Farrell <[email-masked]> on 05/10/2000 06:43:04 AM

Please respond to [email-masked]

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: DER in ac509prof-03

"DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]"
is fine by me, anyone else care?

I guess this should be the same in the son-of-2459 too.

Stephen.

"Phillip H. Griffin" wrote:
>
> Hi there,
>
> In section 4.1, just after your use of the deprecated
> "ANY" notation, your profile states incorrectly that "DER
> is defined in [X.208-88]". X.208 defines Abstract Syntax
> Notation ONE (ASN.1), but it does not define any of the
> ASN.1 encoding rules.
>
> Way back in 1988, the time period to which you refer, the
> ASN.1 encoding rules were defined in X.209. Of course both
> X.208 and X.209 have been superseded and relegated along
> with their lists of unresolved defects to the maintenance
> site, at http://www.furniss.co.uk/maint/asn/index.html.
>
> In 1988, only BER existed as an ASN.1 standard, as defined
> in X.209 (though X.509:88 defined a set of restrictions on
> X.209 that they called DER). The DER, PER and CER encoding
> rules were not standardized until 1994. It could be that
> you are referring to "[X.509-88]" in your document rather
> than the current version of X.509 (which defines ACs) to
> try to include some sort of DER support for X.208/209 -
> hard to tell.
>
> The initial DER was created by Hoyt Kesterson's X.509 group.
> Out of their efforts, the ASN.1 DER rules evolved, and are
> now defined in the current ASN.1 standard, X.690. Though the
> spirit of X.509-88 and X.690:DER are the same, X.690:DER
> corrects a number of oversights present in X.509-88. These
> two rule sets differ in slight ways, particularly in how
> bit string values and a few other very small details are
> handled. These distinctions become important when digital
> signatures are involved.
>
> A good description of DER can be found in a free download
> copy of the recent ASN.1 book by John Larmouth, called ASN.1
> Complete, at http://www.nokalva.com/asn1/booksintro.html.
> Hard copy is also available from B&N (not for free I think).
> All of the wrinkles and warts are discussed. Worth a read
> if you have to deal often with such things.
>
> Phil
> ----
> Phillip H. Griffin      Griffin Consulting
> http://asn-1.com        Secure ASN.1 Design & Implementation
> +1-919-832-7008         1625 Glenwood Avenue, Five Points
> +1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
> ------------------------------------------------------------

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 May 2000 16:38:25 +0100

Tom,

> son-of-2459.  

No problem. 2459 does it that way in the text, but not in 
the ASN.1 module, which I guess must be where I copied it
from.

> Since only SecurityCategory, among the structures specific to

Wasn't there consensus among the folks in Adelaide to expunge the '93 
ASN.1 from son-of-2459. I'm happy to follow whatever happens there, 
though I can't remember if this has come up on the list.

> implementations (if there are any), 

There are. 

Regards,
Stephen.

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 May 2000 12:29:20 -0400

Yes.  The group was asked if anyone wanted to retain the ASN.1-1993 
Appendix, and no one cared enough to speak up.

Russ

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Wed, 10 May 2000 15:54:27 -0400

> Appendix, and no one cared enough to speak up.

Actually the PKIX1Explicit93 module is now referenced in an
IMPORTS statement in the FDIS version of ISO 15945 (also an
ITU-T proposed standard, but I can not find the mumble number
right now) Trusted Third Parties. 

This work includes versions of CRMF and OCSP whose syntax has
been corrected where necessary and rewritten using the current
ASN.1 standards. 

Phil